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The informations contained in this manual can be modified without warning. 


FOREWORD 


This revised definition of the LIS language comes two 
years after the earlier, October 1972 definition of the 
language. The revision has resulted in a simpler syntax 
and an increase of the semantic possibilities. 


Several people have helped us in this revision. Both 
J.J. Horning (Toronto) and M. Rain (Trondheim) made 
systematic in-depth studies of the earlier language and 
suggested general improvements. The work on _ the 
orthogonalization of the syntax was _ influenced by 
proposals from G. Kahn and B. Lang (Iria), and B. Kahan. 
The work on system aspects benefited from discussions 
with A. Woodcock, L. Segonzac and R. Watremez. 


Last, but not least, the pratical experience accumulated 
by L. Asfar, R. Beretz, P. Douspis, V. Dulich, G. Ferran, 
E. Morel, C. Renvoise, D. Salembier, H. Savary, J. Teller 
and R. Tinker in writing two LIS compilers proved in- 
valuable in the reassessment of the language and in its 
simplification. 


The development of LIS has been supported by 
research contracts with DRME and SESORI. 
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1. Introduction 


1-1. General goals of the LIS language —_ 


The system implementation language LIS belongs to the same stream of 
thougth as the languages PASCAL, SUE, and SIMULA. Along with these, 
LIS tries.to be normative and to lead its users towards clear and error-free 
‘programming. Major emphasis has therefore been placed on the readability 
and the descriptive quality of programs. To that end, the concepts of types, 
“symbolic types and data structure types have been introduced to transmit 
important semantic information in the programs. Similarly, control struc- 
tures have been designed so as to facilitate the writing of texts which are 
readable in a natural manner; i.e., linearly, without forward references. Final- 
ly, the concept of normalized presentation has been adopted (paragraphing 
of programs). - 


A second goal in the LIS definition was to reach a high reliability level at the 
very time programs are written. To reach that goal, special care was taken in 
order to avoid error-prone linguistic forms. In particular, any positional nota- 
tion has been carefully avoided. Many features of the language were con- 
ceived so as to allow coherence. checking at compile time. Many errors:can 
be detected at compile-time using information available from the types. 


Optional mechanisms for run-time error detection have been defined, for 
other, more. complex, classes of errors. These mechanisms should be used 
for debugging, or even during the first production runs of a program. 


There is clearly an intrinsic difficulty in the attainment of reliability in a 
system implementation language. High reliability can only be obtained in a 
high level language, and by restricting the nature of possible operations. 
These restrictions are sometimes unacceptable in systems programming. 
The solution chosen in LIS is to allow these operations only within the con- 
text of some particular constructions of the language, that is, in implementa- 
tion parts and interfaces. Hence, the major part of a program can be written 
in a high level language, with a high reliability level. The few parts using a 
lower level language can be easily localized in the text of the program, and 
the user can concentrate his efforts on these sensitive points. 


A third goal in the LIS definition was to allow the writing of programs in 
such a way that changes and later adaptations would be made easier. 


An important cause of modification in programs, during writing as well as 
during later changes, arises with data structures. LIS facilitates these 
modifications by splitting the data definition into two phases. During the 
first. phase, data properties are only considered as they are used in the 

' algorithms manipulating them. It is only during the second phase, called im- 
plementation, that the actual data representation is defined. This implemen- 
tation can then be modified without changing the text of the algorithms 
operating on data. 


For other causes of program adaptation such as transfers from one machine 
to another the programming language and the compiler used are of great 
importance. 


Transferability from one machine to another is a very complex problem 
which can be solved only partially by mechanical means. In LIS, this 
problem is simplified by the previously mentioned textual separation into 
parts using languages with different levels. Parts written in the high level 
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1-2. Language summary 


1-2.1. Types 


1-2.2. Expressions and statements 


language can be transferred mecharucally. On the other hand, parts written 


in the lower level lanquage mchudie somme machine dependent elements, and 
may have to be rewritten (by hand} for a transfer. Note that the frequency of 
such rewriting has been reduced by imcreasing the power of the transfor- 
mations performed by LIS compdlers. These include global optimizations. 


A final, practical, goal was to sympisfy partial treatments. In particular, it was 
deemed desirable to fnit the scope of the recompilations which must be 
performed for local program modifications. To that effect, a segmentation 
into seperately compdable units has been introduced in LIS, and this 


.segmentation is integrated into a block structure. 


Programs consist of algorithms defined by statements which operate on 
data. The properties of data are defined in declarations and, optionally, their 
actual implementation may be given in implementation specifications. 


‘Data items are variables or constants. Each variable or constant is in- 


troduced by a declaration which defines its name, type and, possibly, its in- 
itial value. 


A type represents a set of properties which are possessed by the elements 
of this type. The types BOOLEAN, CHARACTER, INTEGER and TEXT are 
predefined. Other types may be constructed by means of type declarations : 


— Discrete symbolic or discrete integer types. 
— Set types. - 
— Plex types (structured data or data abstractions). 


Some types correspond to collections of data items of the same type : 


— Array types and row types. 
-- Domain types. 


The types of the variables which are used to refer to items of these collec- 
tions are: 


— Index types. 
— Reference types. 


By extension, the type concept is also applied to: 


— Subprogram types. 
— Connector types. 


An expression defines a rule for computing a value by application of 
operators to operands. The language has a fixed set of operators subdivided 
into: 


— arithmetic operators, 
— boolean operators, 


-— set operators, 


— relational operators and the operator /N, 
— the operators REF and ROW. 


An operator can be regarded as describing a mapping from the operand 
type(s) into a result type. 


1-2.3. 


Subprograms 


1-2.4. Compilation units 


1-2.5. 


Implementation parts 


Language summary 


The most fundamental statement is the assignment statement. It causes the 
value of an expression of a given type to be assigned to a vetlel of the, 
same type. 


Other statements, called control statements, cause ihe repetition or the 
selective execution of lists of statements : 


— if statements, 


— case statements, 


_ — loop statements, 


— loop exit statements, 
— subprogram calls, 
— return statements. 


Special statements are used to allocate or free plexes in a domain. Symbolic 
output statements serve to display the values of data items in a readable 
form. 


A list of statements may be given a name. It is then called a subprogram and 
the occurence of its name is'a subprogram call which causes the execution 


of the associated statement list. 


A subprogram may have parameters and include local data declarations. 
Values can be passed to a subprogram by means of value parameter 
assignments. Alternately, values computed within a subprogram can be 
returned by means of result parameter assignments. 


Several kinds of subprograms may be distinguished : 


— procedures (recursive subprograms), 
— actions (non-recursive subprograms), 
— coroutines. 


A function is a subprogram (action or procedure), the evaluation of which 
yields a result of a type specified in the function declaration. A function call 
may be used as operand in an expression. Side-effects are not allowed in 
functions. 


A connector is a subprogram variable. The call of a connector invokes a sub- 
program previously assigned to the connector by a connection statement. 


Programs are divided into separately compilable compilation units. These 
may be: 


— Data segments, 
— Program segments, . 
-- Data partitions, 
— Program partitions. 


Segments are hierarchically organized. Their hierarchy defines the rules of 
visibility of declared identifiers. It also serves for the determination of the 
segments which must be recompiled for a given program modification. 


Partitions are used to split segments into smaller compilation units. They 
also serve to refine the visibility rules. 


A data implementation part contains implementation specifications which 


serve to implement symbolic and plex types, domains and arrays, and also to 


‘specify linkage conventions for non standard subprograms or for sub- 


programs written in another language. 


An implementation schema is used for a domain implementation. It defines 
the actual operations performed by the operators ALLOCATE and FREE for 
the plexes of the domain considered. 


Lower level notions such as addresses, operations on references, words, 
bytes,..., may only be used in data and program implementation parts. Final- 
ly there is a possibility for dynamic type coherence tests. 
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2-1 . Syntactic notation 


2-2. Input and output formats — paragraphing 


2. Preliminaries 


a 


The Backus-Naur notation (BNF) is used for syntax description. Each - 
syntactic category is represented by a word, or a sentence, surrounded by_ . 
the brackets <and>. The key-words of the language are written the wey 

they appear in programs. 


_ To facilitate the reading of the syntactic definitions, different alternatives of 


one definition are written on contiguous lines beginning with the character !. 


Syntactic categories representing successions of elements have been called 
lists when there is a terminator after each element. They have been called 
sequences when there is a separator between consecutive elements. 


. ._ A program is written in the form of a sequence of lexical elements possibly 


separated by blanks depending on whether the nature of these elements 


_ makes this separation necessary or not. 


The output format of a program is independent of the input format. When a 
listing of a program is requested, the compiler arranges the text of the 
program according to the paragraphing rules. In the paragraphed texts 
systematic spacing conventions are followed and indentations are used to 
make the major language constructs stand out clearly. For example, the | 
following text : 


IF SI IN OPTIONS THEN INPUTFORMAT 

:= SYMBOLIC ;ELSIF CI IN 

OPTIONS THEN 
INPUTFORMAT —:= COMPRESSED 
ERROR ;: END é 


: ELSE 


will be restituted in the paragraphed form : 


IF SI IN OPTIONS THEN 


INPUTFORMAT  := SYMBOLIC : 
ELSIF Cl IN OPTIONS THEN 
INPUTFORMAT := COMPRESSED ; 
ELSE . 
ERROR ; 
END ; 
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- 2+3. :Lexical elements a a ar 


The lexical elements used in a program belong to the following lexical 
- catégories » ; 
(1) Special symbols 
_ (2) Reserved identifiers 
_ (3) Identifiers 
(4) Integer literals 
(5) Character strings 
‘~~ (6) Comments 


All lexical elements are composed of characters of the EBCDIC character 
set. Characters are often classified in the following subsets : 
(a) Alphabetic characters 
ABCDEFGHIJKLMNOPOQRSTUVWXYZ 
» (b) Numeric characters - 
' 0123456789 
_ (e} Hexadecimal characters 
| 0123456789ABCDEF 
~ (d) Special characters oo 
<+le()s-/,>:@+$#' 
. (e) The-underscore.character . 


- 2-3.1. Special symbols _ _ | Special symbol ‘Meaning - | 
. dot| its 
interval separator 


< = _ . less than (or opening bracket) 
<= . ° less than or equal to 
od . - opening parenthesis 
ok 7 . plus (or absolute value) 
| separator 
Ko: _ multiply 
) closing parenthesis 
~ minus 
le divide | 
/= . not equal to 
; - comma _.- . 
> greater than (or closing bracket) 
>=, greater than or equal to 
oO colon 


a2 _, . assignment (or, value parameter assignment) 
I= ; . value result parameter assignment 
@ _ dot for standard attributes 
tc - .result parameter assignment 
see initialize with 
— . equal to. 
; semi-colon 


2-3.2. Reserved keywords 


2-3.3. identifiers 


2-3.4. Integer literals 


. Preliminaries 


ACTION EACH NIL SCHEMA 
ALLOCATE ELSE NOT SEGMENT 
AND ELSIF NULL SET 
ARRAY END 
AS EXIT OF 

- EXTERNAL OR © TEXT 
BASED OTHERS THEN 
BEGIN FALSE . OUT TO 
BIT _ FLOAT TRUE 
BOOLEAN FOR PACKING TYPE 
BYTE FREE PAGE 

FROM PARALLEL 

PARTITION UNION 

CASE HALF PLEX UNTIL 
CHARACTER . PREFIX USE ‘* 
COHERENT IF PRIVATE 
CONNECTOR IMPLEMENTATION PROCEDURE 
CONSTANT IN PROCESS VALUE 
COROUTINE INTEGER PROGRAM. VULNERABLE 

INTERFACE <a 

REF 

DATA LINE REGION WHILE 
DO LOOP REPEAT WITH 
DOMAIN RESERVE WORD 
DOUBLE MAIN RETURN 
DOWNTO MODULO ROW XOR 


An identifier is formed by a string of up to 64 alphabetic, underscore, or 
numeric characters, the first character being alphabetic. All the characters of 
an identifier are meaningful. 


Examples : 
JULES RED xX DICTIONARY A 
OPEN SNOBOL4 12 DICTIONARY B 


‘Usually a given identifier will appear in many places in a program. The lex- 


ical category <identifier> is used to represent undeclared identifiers. An un- 
declared identifier may only appear in a declaration. For later occurrences of 
that identifier, the properties given in its declaration are known. Conse- 
quently lexical categories reflecting these properties are used for already 
declared identifiers : 


<interface name> 
<schema name» 
<variable name> 


Carray or row name> <domain name> 
<loop name> <program name» 
<symbol> < type name> 


Both <array or row name> and <variable name> are included in the 
category <variable>. 


Numbers belong to the lexical category <integer literal>. They may appear 
under two forms : 


_(a) decimal numbers are composed of a sequence of numeric characters, 


(b) hexadecimal numbers are composed of the special character # followed 
by a sequence of hexadecimal characters. 


Examples : 

12 133 0 

7 40 Zt F7BA # OOOOO000 
Note: 


Later occurrences of an identifier initially defined in the declaration of a 
static integer constant (see 3-0.3.2.) also belong to the lexical category 
<integer literal>. 

Thus, the identifier L/VES/ZE declared as representing the literal 80 will be 
considered as the latter in expressions such as L/NES/ZE + X. 


ed 
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2-3.5. Character strings 


2-3.5.1. Type of a string 


2-3.5.2. Remark 


2-3.6. Comments 


2-3.7. Use of blanks 


y 


A string element is composed of a sequence of. one or more EBCDIC 
characters enclosed by two quote characters and fitting on a single line. 
Within a string element the quote character is represented by two con- 
secutive quotes (the string element containing a single quote character is 
written ‘""’). 


Examples of string elements : 


‘ONE ELEMENT’ = ANOTHER ELEMENT" 
‘AB*/$@$BLABLA’ ‘72’ ‘JOHN’S WIFE’ 


A string is made of a sequence of one or more string elements separated by 
one or more blank characters. These string elements are implicitly con- 
catenated. Thus the string elements: 


‘FIRST PART’ ° AND ' 
‘SECOND PART’ 


are equivalent to : 


‘FIRST PART AND SECOND PART’ 


The type of a string of N characters is 


ARRAY (0..N-1) OF CHARACTER: 
A string is a literal and hence a static constant. 
The predefined type CHARACTER (see 3-1.4.3.) is assimilated to a symbolic 


type whose symbols are the EBCDIC characters. To take that fact into ac- 
count, character strings having only one character are desimllatee to Sym: 


- oo 


A comment is a sequence, of any length, of EBCDIC characters (except $) 
delimited by the character $ at the start and the end. 


Examples : 


$ THIS IS A COMMENT $ 
$*'AA' US 


A comment is equivalent to a blank and may appear between any two lexical 
elements. On the other hand a comment cannot appear within another lex- 
ical element. Thus a $ used in a character string will be considered as a 
character and not as the beginning of a comment. 


A comment following a given lexical element will be paragraphed on the 
same line as that element if it fits on that line, otherwise it will be 
paragraphed on the following line(s). Lexical elements following a comment 
will not be paragraphed on the same line as the comment. 


One or many blanks must be used between two successive lexical elements 
unless one of these elements is a special character, a comment or a string. 


The omission of a blank can introduce errors. So, EVDSEARCH will be con- 


sidered as an identifier and not as the succession of the reserved word EVD 


and the identifier SEARCH. With standard paragraphing, however, such 
errors generally lead to a drastic change in the form of the listing and are 
hence easy to detect. . - 


An end of line is equivalent toa blank. 
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3-0.1. Syntax of declarations 


3. Language elements and declarations - 


. .The main elements which can be named in a LIS program are variables, 
~ domains and subprograms. All elements must be declared. The declaration 


of an element introduces the name of the element and associates a type 
with that name. It may also specify that the element is CONSTANT or 
PRIVATE. For variables, it may also include an initialization. 


Each element has a type which defines a set of properties common to the 
elements of that type. Thus, the type of a variable defines the set of possible 
values for the variables of that type. The type of a subprogram defines the 
names and types of its parameters and, in the case of functions, the type of 
the result. 


The language has the predefined types BOOLEAN, CHARACTER, INTEGER 
and 7EXT. In addition, new named types may be introduced by type 
declarations. 


<declaration> «= . 
<element declaration» 

| <type declaration) 

! <variable part> © 
! <segment declaration» 
| <partition declaration) 
! <implementation ape ciicationy 
! NULL 


clement declaration) «= 
“sequence of identifiers» : nature» <type> <initialization> 
, <sequence of identifiers> : <nature> <type> 
.<sequence of identifiers» : <type> <initialization> 
“sequence of identifiers» : <type> 


<sequence of identifiers «= 
<identifier> , <sequence of dentists? 
! <identifier> 


| nature» = 


CONSTANT | 
! PRIVATE 
1 <mode> 


<type declaration) #= 
TYPE <identifier> = <type> 


<type> «= 
<discrete es: 
! <set type> — 
! <plex type> 
! <array type» 
! <row type» 
! <index type> 
! <domain type> 
! <reference type> 
! <subprogram type» 
! <connector type> 
| <type name> 


initialization) #= 
== <expression> 
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3-0.2. Examples 


3-0.3. Semantics 


10 


Declarations z 


|, VOLUME :(1.. 1000); 

CAR : PRIVATE CHARACTER ; 

TRIBE : DOMAIN OF PERSON ; 
SCANNER : COROUTINE ; 

READINTEGER : ACTION (X:IN INTEGER): 


Type declarations : 


TYPE CHAR = CHARACTER ; 
TYPE ALPHA = ARRAY (0.. 20) OF CHARACTER ; 


“TYPE FORM = ( TRIANGLE | RECTANGLE | CIRCLE ) ; 
TYPE PERSON = = 


PLEX 

NAME, FIRSTNAME : ALPHA ; 
AGE: INTEGER ; . 
FATHER, SON : REF PERSON ; 

END: 


Declarations with initializations : 


CREATED, MODIFIED, DESTROYED : BOOLEAN == FALSE ; 
MAXNODE : CONSTANT INTEGER == 500 ; 


_ ARTICLELENGTH, LGMAX : CONSTANT INTEGER == MAXNODE ; 


Note: 


All declaration and statement examples which appear in this manual are 


~ given with the semi-colon which normally follows them (a statement is 
~ always followed by a semi-colon ; the only case of declaration not followed 


by a semi-colon is that of the last parameter declaration of a sequence of 
parameter definitions). 


A type declaration is used to give a name to a type definition. This name can 
later be used in element declarations and in other type declarations. 


Identifiers which appear in the sequence of identifiers of an element declara- ~ 
tion get the type indicated in this declaration. They get at the same time the 
properties associated with that type. 


The lexical categories of declared identifiers are the following : 


Type Lexical category 

discrete variable name> 

set <variable name> 

index . <variable name> 

reference <variable name> «variable > 
plex _ variable name> 
array ss array or row name> 

row _ ss array or row name> 

domain <domain name> 

subprogram _ <program name> 

connector <program name> 


3-0.3.1. Life-time of declared entities 


3-0.3.2. Constants 


3-0.3.3. Private Entities 


3-0.3.4. Remark 


ba nguage elements and declarations 


The type associated with identifiers in their declaration may be a new type ; 
definition or the name of a type previously defined in a type declaration. 


The predefined type names BOOLEAN, CHARACTER and /NTEGER are 
assimilated to discrete types with special properties (see 3-1.4.). 


The predefined type name 7EX7T is assimilated to an array type (see 3-4.6.). 


An initialization may be provided in the declaration of a variable. It is man- 
datory if the nature is CONSTANT. 


A declaration which appears in a given subprogram is reevaluated upon 
each call of this subprogram. As a consequence, the life-time of a declared 
entity extends from the evaluation of its declaration until the end of the ex- 
ecution of the containing subprogram. 


In practice, this means that a variable must be considered as a new variable 
for each call of the containing subprogram (possible initializations being 
recomputed). It also means that the variable will not retain the value com- 
puted during a previous call of the containing subprogram. 


A constant declaration must include the keyword CONSTANT and an 
initialization. 

A constant is called a static constant if the initialization can be evaluated at 
compile-time. Static constants are treated as literals. 


A constant is called a dynamic constant if the initialization can only be 
evaluated at run-time. Dynamic constants belong to the category 
<variable>. The initialization of a dynamic constant is evaluated upon entry 
of the subprogram enclosing its declaration. The value of such a constant 
remains unaltered during the execution of the subprogram. On the other 


_ hand it may differ from one call to the next. 


“The compiler will detect any attempt to modify the value of a constant 
‘ (static or dynamic). Hence it is a good programming practice to declare as 


constant any entity whose value, once initialized, should be protected 
against any modification. > 


Domains, subprograms and connectors cannot be declared with a constant 
nature. : 


A private entity is an entity declared with the nature PR/VATE. A private 
entity is visible at the level of its declaration but its visibility is not inherited 
within subprograms which are inner to the subprogram, segment or partition _ 
where the declaration is made. 


For segments and partitions, the following rule is applied. A private entity 
declared within a data segment (or data partition) is visible within the 
program segment (program partition) of the same name. 


The notion of visibility is explained in chapter 6 (see 6-1.3., 6-3.3., 6-4.3.). 


See also 3-3.3.4. for the meaning of PR/VATE for attributes. 


The concept of type contributes to the readability of programs since it 
permits factoring of program elements into groups of elements sharing com- 


- mon semantic properties. It also contributes to the security of programming 


since it enables the compile-time detection of some errors. Thus, the types 
of elements which form expressions and statements must be compatible 
and this can in general be checked at compile-time. 


11 
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3-1 . Discrete types 


3-1.1. Syntax 


3-1.2. Examples 


12 


Cai discrete type > == 
<discrete integer rN 
! <discrete symbolic type>- 


<discrete integer type> #= 
( <interval> ) 


alia 


<simple expression) . _<simple eupreasicns: 


discrete symbolic type> s= 


<simple aera aR . 
!_ <compound symbolic wpe? 


<simple symbolic type> == 
( <sequence of symbolic values> ) 


<sequence of symbolic values» == 
<sequence of snare values > | Seer 
-! identifier > 


<compound symbolic type> #= 
UNION: <symbolic range list> END 


symbolic range list> #= 
<symbolic range list> evnibolie range» ; 
-<symbolic range>; 


<symbolic range» «= | 
TYPE <identifier> = <discrete symbolic type> 


- Discrete symbolic type : 


( FIXED | VARIABLE | UNDEFINED ) 


Simple symbolic type declarations : 


TYPE ORGANIZATION = ( CONSECUTIVE | INDEXED | PARTITIONED ): 
TYPE INTERRUPTMODE =(PS|UI| NAO|NI| NMA|PSM|MPV); 
TYPE UNITYPE = ( DIAM | PRINTER) ; 
TYPE OPCODE = (LW|CW|STW|AW|SW| MW | DW); 
TYPE ADDRESSMODE =( DIRECT| INDIRECT ) ; 
Compound symbolic type declaration : 
TYPE COLOR = 
UNION 
TYPE DARK = 
UNION 
TYPE WARM = (RED de 
TYPE COLD =( GREEN | BLACK | BLUE 3 
END: 
TYPE LIGHT = ( YELLOW | ORANGE|WHITE); 
END; 


Discrete integer types : 

(0..255) 

(1..LGMAX + 10) 

Discrete integer type declarations : 


TYPE KEYLENGTH =(1..256); . 
TYPE KEYPOSITION =(0..ARTICLELENGTH ) ; 
TYPE SHORTINTEGER =(0.. 4096); 


~ Symbolic type variable declarations : 


TRAPCAUSE : INTERRUPTMODE ; 

SHADE : COLOR ; 

INPUTFORMAT : (SYMBOLIC | COMPRESSED ) ; 
SINGLE, MALE : BOOLEAN ; 


— 3-1.3. Semantics | 


3-1.4. Predefined discrete types 


3-1.4.1. INTEGER 
3-1.4.2. BOOLEAN 


3-1.4.3. CHARACTER 


Language elements and declarations 


The value of a variable belonging to a discrete integer type can be any 
integer value of the interval mentioned in the type definition (bounds in-. 
cluded). The bounds must be compile-time computable simple ERDIESsIOns: 

the left bound must be smaller than the right bound. 


The value of a variable belonging to a discrete symbolic type can be any of 


the symbolic values mentioned in the type definition. The order in which 


symbolic values appear in a discrete symbolic type is meaningless. 


The name of a symbolic range belongs to the lexical category <type name>. 
It is used to represent the corresponding symbolic values in label parts, 


_. membership relations and case statements (see 3-3., 4-2., 5-4.). On the 


other hand, identifiers cannot be declared as belonging to a symbolic range. 


' The same identifier cannot appear in the lists of symbolic values of two dis- 


crete symbolic types, if these types have a common scope. 


The language provides no direct possibility of knowing the internal code 
used by the compiler for a given symbol. The possibility to assign specific in- 
ternal codes to symbols is only offered in an implementation part (see 7-3.). 


There are three predefined discrete types with special semantics. 


INTEGER is a predefined discrete integer type. Its bounds are respectively 
the smallest and the largest possible integer values on the machine con- 
sidered (see 4-1.3.5.). 


The type BOOLEAN may be considered as a predefined symbolic type with 
the two symbols TRUE and FALSE. Unlike normal symbolic types, however, 
its symbols are ordered with the relation FALSE < TRUE. 


The type CHARACTER may be considered as a predefined symbolic type 
whose symbols are the EBCDIC character literals. Unlike normal symbolic 
types, however, character values are ordered by their EBCDIC codes (see 
also section 2-3.5.2.). 


oe OL LV CS a ae a ee Se 


3-2.1. Syntax 


3-2.2. Examples 


3-2.3. Semantics 


<set type» «= 
SET OF discrete type» 
| SET OF <type name> 


Sets defined on a symbolic type : 


BLEND : SET OF COLOR ; 
TRAPSET : SET OF INTERRUPTMODE ; 
OPTIONS : SET OF (SI| Ci| CO| GO| LS| LO| so| OL) 


Set defined on an integer type : 


PREDECESSORS, SUCCESSORS : SET OF (O.. MAXNODE) ; 


The discrete type which appears in a set type is called the base type of the 
set type. The values of variables of a given set type are sets of values of its 
base type. 
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3-3. Plex types 


3-3.1. Syntax 


3-3.1.1. Syntax of plex types 


3-3.1.2. Syntax of label parts 


3-3.2. Examples 


Clennney 2 
PLEX <list of attribute senanignes END 


<list of attribute definitions) s= 
<declaration ist? 


variable part> #= 


CASE <attribute> OF <variant list> END 
!. CASE <discrete type> OF <variant list> END 
! CASE <type name» OF <variant list) END 


<variant list > s= 
<variant list) <variant> 
- Cvariant> 


Cesar i 
<label patty : list of attribute definitions > 


<label part) «= 
< <sequence of labels) > 


<sequence of labels» «= 
<sequence of fabeley. | <label> 


| <label> 


Gabel) 
<symbol> 
| <integer literal> 
| <type name> 
| <interval> 
! OTHERS | 


Plex types containing only simple attributes : 


TYPE DATE =. 
PLEX 
DAY :(1..31); 
MONTH :(1..12): 
YEAR :(0..2000); 
END; 


TYPE INSTRUC = 
PLEX — 
“ADDRESSING : ADRESSMODE ; 
OPERATION : OPCODE ; 
~OPERAND.:(0..15); 
INDEX :(1..8); 
ADDRESS :(0.. #TFFFF) ; 
-END: 


Plex variable declarations :- 


~ CURRENTIDENT : DESCRIPTOR ; | 
INPUTUNIT, OUTPUTUNIT : PERIPHERAL ; 


IMP, TELETYPE: FILE: 
ME :PERSON: 
TODAY: DATE: > 


Language elements and declarations — 


Plex type including a dynamic array: 


TYPE FILERECORD = 
PLEX 
LENGTH :( 1... ARTICLELENGTH) ; : 
IMAGE : ARRAY (1... LENGTH ) OF CHARACTER ; 
END; ; 


Plex type declarations Including pareble paris 


TYPE PERIPHERAL = = 
PLEX 
STATUS : SET OF. (OPEN! INPUT| FIXED); 
UNIT :( PRINTER| DISK | DRUM) ; 
_ CASE UNIT OF 
<PRINTER> : LINECOUNT : ( 1... 55); 
<DISK| DRUM> : 
— CYLINDER :(1..200); 
TRACK :(1..8); 
END ; . . . 
END ; 


TYPE DESCRIPTOR = 
PLEX 
KIND : CONSTANT (REAL| INT| BOOL ) ; 
LENGTH :(1.. MAXIMUM ); 
IDENT : ARRAY (1... LENGTH ) OF CHARACTER : 
NATURE :( VARIABLE| PROCED| TABLE) ; 
CASE NATURE OF 
_<VARIABLE> : ADDRESS : INTEGER ; 
<PROCED>: 
PARANUM :(0..10); 
MODE: ( RECURSIVE | NONRECURSIVE ): 
CASE MODE OF 
<NONRECURSIVE> : DATAADDRESS : INTEGER : 
<RECURSIVE> : NULL ; 


END; 
<TABLE> : 
_ TABLEADR : INTEGER ; 
INDEX :(1..5);. 
END: 
END; 


Variable part without variant selector : 


CASE BOOLEAN OF 
<TRUE> : NUMBER : INTEGER : 
<FALSE> : | 
HIGHPART : (0... 2000); 
LOWPART :(0.. 2000) ; 
END; , 


Plex type including subprogram declarations : 


TYPE PERSON = 

"PLEX 
BIRTH : CONSTANT INTEGER ; 

_ LASTAGE : PRIVATE INTEGER ; 
GETAGE : ACTION ( AGE : OUT INTEGER ): 
FATHER : REF PERSON ; 

END; 


PROGRAM PERSON. GETAGE: 
BEGIN 
IF NEWYEAR THEN 
LASTAGE := THISYEAR — BIRTH ; 
END ; 
AGE := LASTAGE ; 
END; 
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3-3.3. Semantics 


aaa 


3-3.3.1. Variable part . 


-3-3.3.2. Label part 


3-3.3.3. Attribute subprograms 
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—Inits simplest form, a plex type defines a model of data structure made of a 


fixed number of elements called attributes. The names and types of these at- 


tributes are introduced in the attributes definitions. 


More generally, a plex type may include variable parts and hence defines a 
family of models of data structures. Element declarations and variable parts 
are the only forms of declarations allowed in a list of attribute definitions. 


The attribute names introduced in a plex type declaration are visible within 
that declaration. These attributes are also visible by means of indirect names 
(see 4-1.3.1.), in an aggregate primary (see 4-4.), or in attribute sub- 


Programs: ‘of the plex type considered. 


~~ All attribute names appearing in a given plex type, variable parts included, 


must be different. 


The first form of variable part includes an attribute name, called the variant 
selector, which must belong to a discrete type. Each variant defines the at- 
tributes which exist in a plex for the corresponding value of the variant 
selector. A given attribute may be used as selector in several variable parts 
belonging to the same plex type declaration. 


In the second form of variable part, variants are associated with all possible 
values of the discrete type (or discrete type name) mentioned. However 


there is no variant selector. As a consequence, it will generally not be possi- — 
ble to establish from the value of some attribute which variant is present in a 


given plex. This second form should hence be used with the greatest care. 


An attribute array whose upper bound is itself an attribute of the plex is 
assimilated to a-variable part. In this case the upper bound is considered as 
a variant selector and the array attribute is a dynamic array, whose size is 
only known when -the plex is allocated (see 3-4.3.2.). 


A label part is a list of symbols or of integer literals (numbers or static 
integer constants). A type name of a symbolic range in a label part is 


' equivalent to the symbols of the range considered. Similarly the type name 


of a discrete integer type or an interval (with integer literal bounds) are 
equivalent to the integers of that type or interval. 


The label OTHERS can only appear as the last label of a variable part. It is 
equivalent to the list of all the values of the selector type which have not 
been mentioned in one of the previous label parts. 


. All values of the selector. type must appear once and only once in the 


variable part. This condition is IMME NEY satisfied if the last label is OTHERS. 


Label parts also appear in aggregate expressions (see 4-4.) and in CASE 
statements (see 5-4.) with a similar meaning and use. 


Plex attributes may ‘be functions or subprograms (actions, procedures, 
connectors but not coroutines). If the plex type is declared in a data segment 
or partition, the program bodies of such attributes must be in the program 
partition associated with the data segment or partition. In all other cases, 
the program bodies must be in the same declarative part as the plex type 
declaration. 


3-3.3.4. Notes on plexes © 


3-3.3.5. Private and constant attributes 


Language elements and declarations 


Plexes can be found in three forms in programs : 


(a) Plex variables : 
They are variables whose declaration includes a type which is a plex | 
type. They are accessed by their names or, indirectly, by a reference | 
variable. 


(b) Plexes belonging to an array of plexes ese 3-4.) : 
_ They are accessed by an index (see 3-5.). 


(c) Plexes belonging to a domain (see 3-6.) : 
They are accessed by a reference variable (see 3-7.). 


Two occurrences of the same plex type denotation are considered as distinct 
types. Thus A and B in the following example do not belong to we same plex 
type : 


A: PLEX 
Z : BOOLEAN ; 
END; 


B : PLEX 
_ Z : BOOLEAN; 
END: 


A PRIVATE attribute can only be accessed by function and subprogram 
attributes. It is not accessible by an indirect name. 


A CONSTANT attribute is an attribute which cannot be modified after its in- 
itialization in the plex \ variable declaration or in an ALLOCATE statement. 


Examples : 


(a) The attribute LASTAGE of the plex type PERSON is private. Hence it 
may appear in the body of the attribute subprogram GETAGE. On the 
other hand, if X is of type PERSON, an indirect name such as 
X.LASTAGE is not permitted. 


(b) The attribute K/ND of the plex type DESCRIPTOR is constant. Hence 
after ALLOCATE Y == (KIND == BOOL....) a modification of the at- 
tribute K/ND such as Y.K/ND := INT is not permitted. 
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_ 3-4. Array and row types ____ 


3-4.1. Syntax 


3-4.2. Examples 


3-4.3. Semantics of arrays 


3-4.3.1. Fixed arrays 


3-4.3.2. Dynamic arrays 


3-4.4. Semantics of rows 
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Carray type» == 
ARRAY <index iaegee OF <element type» 


<row type> #= 


ROW Cindex sae OF eee type > 
.ROW CONSTANT <index metre? OF <element type» 


Cine nature > s=. 


< type a RS | 
- Cdiscrete type» . 


<eletnent type> == 


<type» 


ARRAY (1... 100) OF INTEGER - 

CALENDAR : ARRAY (1..365) OF DATE; 

TITLE : ARRAY (1... 100) OF CHARACTER ; 

PASSWORD : ROW CONSTANT (1..80) OF CHARACTER ; 
UTILITY : ARRAY (1.. NUMBEROFNODES ) OF BOOLEAN ; 


_ INVERSE : ARRAY COLOR OF COLOR ; 


TABLE : ROW (1.. 1000) OF DESCRIPTOR : 
ROWONE, ROWTWO : ROW (1..10) OF INTEGER; 


An array is a collection of variables of a same type. These are called the 
elements of the array. Each element is associated with a value of the dis- 
crete type given as index nature. Array elements may also be accessed by 
variable of type index. 


Two arrays are of the same array type if they have the same index nature 
and the same element type. | 


Depending on the index nature, arrays are either fixed arrays or dynamic 
arrays. 


If the index nature is the name of a discrete type, or if it is an interval with. 
bounds computable at compile time, then the arrays of the type considered 
are fixed arrays. The number of elements of a fixed array (and hence the 
space occupied) is known at compile-time and cannot vary during the ex- . 
ecution of a program. 


A fixed array can be statically allocated (unless it is local toa procedure). 


If the index nature is an interval with a variable upper bound, the arrays of 
the type considered are dynamic arrays. Dynamic arrays are only permitted 
in procedures and in plexes allocated in a domain. The number of elements 
of a dynamic array is known upon entry to the procedure containing the 
array declaration (or upon allocation of the plex containing the dynamic 
array attribute). This number cannot vary as long as the array exists. A 
different number can only be obtained for a new execution of the procedure 
considered (or for a new plex allocation) ; it is then a different array. 


A variable of row type is an array descriptor and can be used to reference 
another array and thus get indirect access to its elements. A row variable A 
is made to designate an array A after the assignment R := ROW A (see 4- 
2.3.7. and 5-1.3.2.). 


Two cases must be considered : 


(a) The row index nature is the name of a symbolic type: 
the array must have the same index nature as the row. 


(b) The row index nature is an interval or the name of a discrete integer 
type : the lower bound of the row is always equal to the value given in 
its declaration. Its upper bound will depend on the array or slice 
referenced. This actual upper bound must always be smaller than or 
equal to the value given in the row declaration. 


3-4.5. Array attributes 


Language elements and declarations 


In the syntax of the language, a row name can be used wherever an array - 
name can be used. 


A variable which is a row constant is analogous to a row. However an array 
element designated by an index to a row constant is read-only. Similarly if 
the denotation of an array element uses the name of a row constant, no 
assignment can be made to that array element (see 3-7.4. for the discussion 
of the properties of reference and row constants). 


Example (using declarations of 3-4.2.) : 
PASSWORD (10) :=‘2'; 
is not permitted since PASSWORD is a row constant. 


Arrays and rows have array attributes which can be read and, for some of 
them, modified at run-time. 


(a) Arrays and rows of discrete integer index nature have the attributes 
FIRST and LAST which are respectively indexes to the first and last ele- 
ment of the array. F/RST is always a static constant. LAST is a static 
constant in the case of a fixed array. It is a dynamic constant for a 
dynamic array in a procedure. It is a variable for a row. It is a selector for 
a dynamic array in a plex. 


(b 


— 


All arrays and rows have an attribute called BASE which designates the 
zeroth element of the array (whether zero belongs to the interval or not). 
BASE is a static constant in the case of a static array, otherwise it is a 
variable. This attribute can be explicitly used only in implementation 
parts. The actual implementation of the BASE attribute is machine 
dependent. 


Array attributes are usually denoted by indirect names surch as 7.F/RST or 
T . LAST for the attributes of an array or row T. In addition, their names may 
appear directly in array elements and slices. Thus 7/F/RST) is a notation 
equivalent to 7/(7.F/IRST/. Similarly T7(F/RST.. LAST) is equivalent to 
T(T.FIRST .. T.LAST). 


Note: 


The attributes LAST and BASE of a row are implicitly modified in a row 
assignment (see 5-1.3.2.). 


3-4.6. The predefined type name TEXT 


The name TEXT can only appear in an element declaration initialized with a 
string. If V is the length of the string, TEXT is an. abbreviation which stands 
for 


CONSTANT ARRAY (0.. N-1) OF CHARACTER 
Thus the declaration . 
A: TEXT == ‘JULES’ ; 
is equivalent to the declaration 
A: CONSTANT ARRAY (0.. 4) OF CHARACTER == ‘JULES’ ; 


As a consequence A is a string literal and is just another way to designate 
the string JULES”. 
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3-5. Index types 


3-5.1. Syntax 


3-5.2. Examples 


3-5.3. Semantics 


3-6. Domain types | 


3-6.1. Syntax 
3-6.2. Examples 


3-6.3. Semantics 


_ -3-6.4. Restriction 
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<index type> s= 
REF <array or row name> 
! REF CONSTANT array or row name> 


(Using the arrays and rows declared in 3-4.2.) 


LEFTCAR, RIGHTCAR : REF TITLE ; 
CURRENTDESCRIPTOR : REF TABLE ; 


* ONECOLOR : REF CONSTANT INVERSE : 


The definition. of an index type mentions the name ofan array (or row) 
previously declared. This array (or row) may also be a parameter or an at- 
tribute. The possible values for a variable of index type comprise all possible 
values defined by the index nature of the array (or row) mentioned. In addi- 
tion, it includes a N/L value if this index nature is discrete integer. 


This association of indexes with arrays simplifies the overflow checks 
generated by the compiler for programs being debugged. These checks can 
be made when values are assigned to indexes rather than when indexes are 
used to access array elements (except for N/L). 


A variable of index type is used to reference an element of an array. If the 


latter is an array of plexes, the index variable may be used to form an indirect 
name (see 4-1.3.1.). 


For the meaning of REF CONSTANT see 3-7.4. 


<domain type> == | 
DOMAIN OF <plex type> 
! DOMAIN OF <type name> 


TYPE FAMILY = DOMAIN OF PERSON ; 
POPULATION : DOMAIN OF PERSON ; 
POOL: DOMAIN OF PERIPHERAL ; 


A domain is a collection of data items belonging to the same plex type. New 
plexes may be allocated in a given domain by ALLOCATE statements ; plex- 
es may be released by FREE statements (see 5-10.). The organization of a 
domain, i.e. how the effect of ALLOCATE and FREE is achieved, may be 
specified in an implementation schema to the domain name (see 7-5.). This 
organization is only known in the implementation part considered. As a con- 
sequence, it is possible to modify a domain organization without having to 
readjust the algorithms which operate on plexes of the domain. 


A domain declaration can only appear in a data segment or partition. The 
implementation schema associated with a domain must be specified in the 
implementation part of that data segment or partition. . 


In the absence of a specification, a standard schema is used by the compiler. 


3-7. Reference types 


3-7.1. Syntax 


3-7.2. Examples 


3-7.3.’ Semantics 


Language elements and declarations 


<reference type> «= 
REF <domain name> 
! REF <type name> . 
! REF CONSTANT <domain name> 
! REF CONSTANT <type name> 


Reference type declaration: 
TYPE DEVICE = REF POOL: 
Reference variable declarations : 


COUSIN, UNCLE, ANCESTOR, KINSMAN : REF FAMILY ; 
UNITCHECKED : REF CONSTANT PERIPHERAL ; 
ONEDEVICE : DEVICE ; 


A reference type definition mentions a domain name {or a plex type name). 
Variables of reference type are used to reference plexes belonging to a given 
domain (or plex variables of a given type). A variable of reference type may 
be used to form an indirect name (see 4-1.3.1.). 


The semantics of assignment statements does not allow the assignment of a 
value of a given type to a variable of a different type. As a consequence : 


(a) A reference variable whose type mentions a domain name may only 
reference a plex belonging to that same domain. 


(b) A reference variable whose type mentions a plex type name may only 
reference a plex variable of the same type. 


3-7.4. Constant reference. and reference constant. 


The language provides for reference constants, constant references (and 
even constant reference constants). In order to discuss their meaning the 
following example will be used : 


TYPE T= 
PLEX 
A: INTEGER ; 
END: 
XY:T: 
R:REF T== REF X; : 
CR: CONSTANT REF T == REF Y; 
RC: REF CONSTANT T == R; 
ROWC : ROW CONSTANT (0..40) OF CHARACTER ; 


(a) Aconstant reference (such as CR) 
always refers to the same object designated in the initialization: No 
assignment may be made to a constant reference. On the other hand 
assignments to the object referenced are possible. Thus CR .A := & is 
legal. 


(b) A reference constant (such as RC) 
refers to an object which cannot be modified indirectly using the 
reference constant. Thus an assignment such as RC .A := 8 is illegal. 
Note that this does not necessarily mean than the object referenced, 
here X, is constant but only that it cannot be modified using the 
reference constant. . 


A reference variable may be assigned to a reference constant. On the other 


~ hand, a reference constant can only be assigned to another reference con- 


stant. Finally, a constant object can only be referenced by a reference con- 
stant. 


Similar rules apply. for row constants. Thus a variable which is a row of 
characters cannot refer to.a string since the literal could be modified. Only a 
row constant of characters (such as ROWC) may refer to a string. 
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3-8. Subprogram types 


3-8.1. Syntax 


3-8.2. Examples 


'3-8.3. Semantics 
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<subprogram type > == 
-<subprogram. nature > ( sequence: of parameter definitions > ) 
! <subprogram nature> - 


<subprogram nature» «= 
- <type name> ACTION 
| <type name> PROCEDURE 
! ACTION 
| PROCEDURE 
! COROUTINE 


<sequence of parameter definitions «= 
<sequence of declarations > 


<mode> == 
IN 


! QUT 
! IN OUT 


Subprogram types: 


INTEGER ACTION (X,Y : INTEGER) 
PROCEDURE (A:IN BOOLEAN :B: : OUT BOOLEAN ) 


Subprogram type declaration : . 
TYPE LIBROUTINE = INTEGER ACTION ( X,Y : INTEGER ) ; 
Subprogram declarations : 


DELETE : ACTION ; 
UPDATE: ACTION (NUM :1IN OUT INTEGER); 
PRINT : ACTION ( MESSAGE : ROW CONSTANT ( 1..100) OF CHARACTER ) ; 


SETDCB : ACTION 
(OPL: ROW CONSTANT ( 1. .10) OF CHARACTER ; 
ORG : ORGANIZATION == CONSECUTIVE ; 
FRM :( FIXED | VARIABLE | UNDEFINED ) === FIXED ; 
REL :( 1.32767); 
KYL: KEYLENGTH ; 
KYP : KEYPOSITION ==0); 


MAX : INTEGER ACTION (X,Y : INTEGER); 
CONVERT : ACTION (1D : REF TABLE) ; 
CREATE : ACTION ( NEWELEMENT: OUT REF POOL): 


Subprograms are program bodies which are named and which can be 
activated by subprogram calls (see 5-7.). The definition of a subprogram 
comprises a subprogram declaration and a subprogram body. Alternately, if 
the subprogram considered is a separately compiled segment, its definition 
comprises a subprogram declaration, a program segment and, optionally, a 
data segment. 


Subprogram bodies, program and data segments may contain declarations 
of entities which are said to be local to the subprograms considered (see 6- 
1. and 6-3.). 


A subprogram declaration associates a subprogram type with an identifier. A 
subprogram type specifies the nature of the subprograms of that type, that 
is, whether they are actions, procedures or coroutines. For a function, the 
subprogram nature also specifies a type name which is the type of the result 
returned by the function. This result can be of discrete, set, index, reference, 
row or plex type. 


A subprogram type also specifies the names, types, and modes for the for- 
mal parameters of the subprograms of that type. 


Actions, procedures and coroutines differ both for the meaning of their calls 
(see 5-7.) and for the memory allocation for their local data. 


_ language elements and declarations 


3-8.3.1. Memory allocation for local data — recursivity 


3-8.3.2. Coroutines 


3-8.3.3. Restriction for procedures 


3-8.3.4.: Parameters 


Three cases must be considered : 


(a) Procedure : 
Memory allocation is done dynamically on a stack upon entry to the 
procedure. 


(b) Action: Pd . 
— If the action is itself local to a procedure, its space is allocated with 
that of the outer procedure. 
—If the action is not local to a procedure, the memory allocation : 
necessary to its local data is done statically. 


(c) Coroutine : 
Memory allocation is done as for an action. 


It follows from these memory. allocation modes that procedures can be call- 
ed recursively. On the contrary, neither actions nor coroutines can be called 
recursively whether directly or indirectly (if a function is called in an expres- » 
sion passed as parameter to this same function). 


in systems programming, the most frequently used subprograms are ac- 
tions. The use of procedures is.a natural way to achieve data overlays. Local 
data of two subprograms, corresponding to two different phases of a 
program, may use the same memory space in the stack if these sub- 
programs are declared as being procedures. 


All the coroutines declared in the same subprogram (the enclosing 
subprogram) form a ‘family of coroutines. A coroutine can be called only by 
the enclosing subprogram or by another coroutine of the same family. 


With each coroutine is associated a /oca/ point indicating where the execu- 
tion of the coroutine should begin. Depending on the nature of the call, the 
local point may be repositioned prior to the execution of the coroutine (see 
5-7.3.3.). 


With the enclosing program is associated an outer point indicating where 
execution of the enclosing program should be resumed when the execution 
of the family of coroutines is finished. 


A procedure must be a separately compiled segment. 


Parameters are elements declared in the sequence of parameter definitions 
of a subprogram type. The parameters of a subprogram are variables local to 
the body of that subprogram. They can also appear in parameter 
assignments. 


The parameter mode specifies which forms of parameter assignments are 
legal for the parameters considered (see 5-7.3.1.). If no parameter mode is 
given, the mode /N is assumed by default. Three cases must be considered 
for the parameter mode: | 


(1) IN only value parameter assignments are possible. 
(2) OUT : only result parameter assignments are possible. 


(3) INOUT :both value and value-result parameter assignments are 


possible. 


The information contained in the sequence of parameter definitions is used 
to check, for each call, that actual parameters, adequate in number and type, 
are provided in parameter assignments (see 5-7.3.2.). 


Parameter definitions including an initialization define default parameters. 
The initialization must be an expression computable at compile-time. This 
expression is assigned implicitly to the parameter when no explicit 
parameter assignment appears in the call. 
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3-8.3.5. Restrictions on functions 
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No tes: 


LIS does not pigida toe array. and subprogram parameters. However : 


(a) An effect similar to that of a subprogram parameter may be obtained us- 


ing a connector. _ 
(b) An effect similar to that of an array parameter may be obtained using a 
row parameter. : 


‘Side-effects are not allowed in functions. It results from the restriction that 


the: meaning of a program will not be changed when the order of evaluation 
of two functions is modified. This restriction is especially useful when 


‘writing aggregate expressions (see 4-4.) and subprogram calls (see 5-7.). It 


implies that the order of the terms of an aggregate expression or of a 
parameter assignment may be modified freely without resulting alteration of . 


~ the meaning of the program. 


The absence of side- effects in 1 functions also simplifies the semantics of 


assignment. statements. (see ‘5- 1.). Thus, the meaning of an assignment 
statement does not depend on whether the evaluation of the right hand ex- 


‘pression or the determination of the left hand variable is done first. 


The implications of that restriction, as for the writing of functions and their 
calls. are the following : 


(a) No assignment to an entity not local to a function can be made within — 


the program body of that function. 


(b) The mode of all function parameters must be /N (value parameters). 


- (c) Parameters and local variables which are references or rows must be 


reference or row constants (see 3- .4.). 

(d) A function cannot execute allocate and free statements on global 
“domains. 

(e) A function cannot call a subprogram modifying data which is global to 


the function. Note that © this last condition cannot be checked 
mechanically in the case of separately compiled subprograms. 


Finally, note that these restrictions do not lead to any limitation of the power 
of the language. They simply lead to a clear discrimination of the cases 
where side-effects are wanted. In the latter cases actual subprograms 
should be used. but not functions. 


Example : 
Ina symbol table management program, we cannot write: 
X := NEWELEMENT ( NAME >= ROW ‘JOHN’ ); 


if the function NEWELEMENT modifies global tables as a side-effect. We 
will rather usé a -subprogram called with a result parameter : 


CREATEELEMENT ( NAME := ROW ‘JOHN’, NEWELEMENT =: X) ; 


3-9. Connector types 


3-9.1. Syntax 


3-9.2. Example 


3-9.3. Semantics 


Language elements and declarations 


<connector type> «= 
CONNECTOR ( <sequence of program names) 


<sequence of program names) == 
<sequence of program names> | <program name> 
! <program name> 


OPERATOR : CONNECTOR (INTDIV | INTPOWER) ; 


The definition of a connector type includes a sequence of names of 
subprograms which must be of a same type and of a same nature. 


A connector initially designates the first subprogram mentioned in the se- 
quence of program names. It may be made to designate another sub- 
program of the sequence by a connection statement (see 5-2.). The call of a 
connector is equivalent to a call of the subprogram designated. 


The use of connectors produces effects equivalent to those obtained in other 
languages by passing subprograms as parameters, without having the in- 
convenience of that method. Thus, the types of the parameters of a connec- 
tor are known. In addition, the optimization of connector calls is easy, since 
the set of subprograms which may be designated by a connector is known 
at compile-time. . 


The name of a connector cannot appear in the sequence of program names 
of a connector definition. 
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4. Expressions 


4-1. Variable and program denotations 


4-1.1. Syntax 


4-1.2. Examples 


<variable> = 
<variable name> 
! array or row name» 


<variable denotation> «= 
<variable > 
! <indirect name> 
! <array element> 
! “<slice> 
Cindirect name> «= 
<primary> + Cattribute> 
! <type name> - <attribute> 
! <standard attribute» 


<attribute» x= 
<variable> 
| <program name> 
! VALUE ~ 


array element) = 


«variable denotation) ( <expression> ) 


sliced == 


«variable denotation> ( Cintaevals ) 
1 variable denotation> ( <type name> ) 
! variable denotation> ( <origin> : dimension ) 
! <variable denotation> ( Corigin> : * ) 


<origin> «= 


<simple expression> 


’ <dimension> = 


<simple expression» 


<standard attribute> == 
variable denotation> @ <standard name> 
! <program denotation> @ <standard name> 
| -<type name> @ <standard name> 


‘<program denotation> == 


<program name> 
! <indirect name> 


‘Variable names : 


PRESSURE (simple variable) 

COUSIN (reference variable) 

-NAME (attribute) . 

FIRST (array attribute, also standard type attribute) 
“NUM => (parameter) 

Array or row names: 

TITLE (array) 

IMAGE (attribute) 

MESSAGE (parameter) 
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4-1.3. Semantics 


’ Indirect names: 


UNIT. STATUS 

TABLE(10) . IDENT(1) 
CURRENTDESCRIPTOR . PARANUM 
COUSIN. FATHER. BIRTH 
COUSIN. FATHER. FATHER 

TABLE . LAST 

TELETYPE . IMAGE 


_ UNIT. VALUE 


. Array elements : 


TITLE (5) 
INVERSE (BLUE) - 


Slices : 


TITLE ( 5..10 ) 
TITLE (5:6) 
TABLE ( FIRST..LAST ) 


Type attributes (standard attributes or indirect names) : 


KEYPOSITION @ LAST 
PERIPHERAL . UNIT 


‘PERSON. GETAGE 


The category <variable> covers declared identifiers of discrete, set, index, 
reference, plex, array. or row type, whether they are declared in a sub- 
program, a segment, a partition, a plex declaration, or a parameter 
definition. 


Dynamic constants are also considered syntactically as variables (on the 
other hand static constants are treated as literals). 

The lexical category <program name> covers identifiers of subprogram or 
connector type. 


An indirect name is used to denote an attribute of a plex, an attribute of an 


array, or the value of a plex or array. It may also be a type attribute or a stan- 


dard attribute. © 


4-1 3.1 . Indirect name of an attribute of a plex 


The attribute belongs to the plex denoted by the primary operand. The latter 
can be: . 


(a) a variable of plex type, 

(b) a reference to a plex variable, 

(c) a reference to a plex of a domain, 
(d) an index to a plex of an array. 


Note that. the primary operand can be a variable or a function call. 


4-1.3.2. Indirect name of an array attribute 


4-1.3.3. Indirect name of a plex or array 


The primary operand must be of array or row type, the attribute must be 
either FIRST or LAST or BASE (see 3-4.5. Array attributes). 


An indirect, name with the attribute VALUE denotes the plex or array 
designated by the primary operand. The latter must be of type index or 
reference (for a plex value) or of type row (for an array value). 


This notation is mainly used in assignment statements. Thus, if X and Y are 
indexes, X . VALUE := Y. VALUE is an assignment of the plex denoted by Y 
to the plex denoted by X. On the contrary X := Y is an assignment of the 
value of the index Y to the index variable X. Similarly, if S and 7 are rows, 
S.VALUE:=T.VALUE is a slice assignment equivalent to. 
S(FIRST..LAST) := T(FIRST..LAST), whereas S :=T is an assignment of the 
row 7 to the row variable S. 


Expressions 


The syntax permits the notations X. VALUE .A and S. VALUE (I) which are - 
equivalent to X.A and S/(/). However these longer notations are not 
recommended. 


4-1.3.4. Array elements and slices A slice designates several consecutive elements of an array denoted by a 
variable denotation which must be of array or row type. 


The index of an array element is given by an expression which may be of dis- 
crete or index type. 


Several possibilities exist for the indexes of the elements of a slice: 


(a) <variable denotation> (<interval>) 
the indexes are all the values of the interval. 


(b 


— 


<variable denotation> (<type name>) 
the indexes are all the values (integer or symbolic) of the type men- 
tioned. 


(c) <variable denotation> (<origin> : <dimension)>) 
the origin must be of type index or discrete integer. The first index value 
is the origin and the number of elements is given by <dimension>- 


(oe 


<variable denotation> (<origin) : «) 
this form can only be used in a slice assignment. The dimension used is 
that of the other side of the assignment (see 5-1.3.3.). 


4-1.3.5. Standard attributes ‘Standard attributes usually serve to denote properties of declared entities 
which are known to the compiler. Most standard attributes are only allowed 
in implementation parts and in parameter assignments of subprograms | 
declared in implementation parts. They are discussed in 7-2.3.4. and 7- 
5.3.4. 


On the other hand, the attributes F/RST and LAST of a discrete integer type 
can be used anywhere. They designate the first and last value of the type 
considered. Thus /V7EGER @ LAST designates the greatest integer on the 
machine considered. 


4-1.3.6. Indirect name of a plex type attribute 


The names of the attributes of a plex type may be denoted by indirect names 
of the form <type name>. <attribute> where <type name> is the name of 
the plex type. 


Thus in the example of 4-1.2., the program denotation PERSON . GETAGE 
represents the action GETAGE declared in the plex type PERSON. 
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4-2. Expressions, primaries and operators__- 


4-2.1.1. Syntax of expressions 


4-2.1.2. Operators 
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expression» #= 


<simple expression» <relational operator > “simple expression > 
<simple expression> 
<membership relation> . 


<simple expression «= 


<simple expression> <adding operator> <term> 


<term> 


Lagi se. 


<term> «multiplying ey <factor> 
<factor> 


<factor> s= 


<unary operator> <primary> 
<primary> 

REF <primary> 

ROW <primary> 


<primary> «= 


<variable denotation> 
«symbol» 

<integer literal> 

NIL 

<set primary> 
<aggregate primary» 
<function call> 

( <expression> ) 


<function call> «= 


<subprogram call> 


<membership relation «= 


<simple expression> IN ae name> 
<simple expression) IN <simple expression) 


<relational Opera = 


4 
' 


Cadel ng operator» s= 


OR 
XOR 


<multiplying operator > ee 


* 


/ 
MODULO 


AND 


<unary operator> «= 


+ 


NOT 


Expressions 


4-2.2. Examples 


4-2.3. Semantics 


Primaries : 

SHADE <variable denotation > 
PASSWORD(J) «variable denotation > 
TABLE(N). PARANUM < variable denotation > 
TABLE . <variable denotation> 
TITLE . LAST < variable denotation > 
GREEN <symbol> 

TRUE <symbol> 

FALSE <symbol> 

52 <integer literal> 
ARTICLELENGTH <integer literal> 
SHORTINT @ LAST < standard attribute > 
MAX(X := UxV,Y:=W) | <function call> 
Factors : 


NOT DESTROYED 
REF OUTPUTUNIT 
UTILITY (NODE) 


Terms: 


PRESSURE « VOLUME 
CREATED AND NOT MODIFIED 
( LINECOUNT + 10) MODULO 55 


Simple expressions : 


( SINGLE AND MALE ) OR ( NOT SINGLE AND NOT MALE ) 
(UxV)+(U/V) 


Expressions : 


CURRENTDESCRIPTOR 
( TODAY . YEAR / TODAY . MONTH ) + TODAY . DAY 


Membership relations : 


SHADE IN WARM 
SHADE IN SET ( BLUE| BLACK ) 


Expressions with a relational operator : 


UNCLE. SIZE > 100 

ORG = CONSECUTIVE 

TITLE( FIRST..LAST ) < PASSWORD( FIRST.. LAST ) 
PASSWORD( 1..5 ) = ‘JULES’ 

ROWONE( 5..10 ) = ROWTWO( 5.. oe 
ROWONE = ROWTWO 


An expression is a formula, describing the computation of a value resulting 
from the application of operators to operands. An expression may consist of 
a unique operand. 


We may distinguish four classes of operator precedences : 


(a) Strong : REF, ROW and unary operators 
(b) medium-strong : multiplying operators 

(c) medium-weak _—: adding operators 

(d) weak :/N and relational operators. 


After evaluation of primary operands, the operators having the strongest 
precedence are applied first. Sequences of operators of the same 
precedence are applied from left to right. 
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4-2.3.1. ‘Relational operators 


4-2.3.2. Membership relation 


4-2.3.3. Adding operators 
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The type of an expression (i.e., the type of the value obtained as a result of 
its evaluation) depends on the types of its primaries and also on the 


operators which appear in the expression. A primary which is a variable, a 


standard attribute, or a function designator has the type defined in the 


declaration of the corresponding identifier. A symbol is either of boolean or 


of a symbolic type. An integer literal is of type integer. Set primaries belong 
to a set type. Aggregate primaries belong either to an array type or to a plex 
type. A primary made of an expression enclosed by parentheses has the type 
of that expression. 


The keyword NIL stands for a null reference, index or row value. As a con- 


~ sequence /V/L cannot be used as primary to form an indirect name. The type 


of N/L is determined by context. For indexes to an array A the value of W/L is 
equal to A. FIRST — 7. 


A function call causes the execution of the program body associated with 
the function, after execution of the parameter assignments if any (see 5- 
7.1.). 


A relation is made of two simple expressions of the same type separated by 
a relational operator. The value of the relation is of type BOOLEAN. It is 
TRUE if the relation is satisfied, FALSE otherwise. 


All relational operators are applicable to values of discrete integer, index, . 
boolean, character or set type with the following meaning : 


equal 

not equal 

less than 

greater than 

less than or equal to 
greater than or equal to 


~ 
I 


VAVA 
ll 


For set values, the operators <= and >= are used for set inclusion ; the 
operators < and > are used for strict set inclusion. Boolean values are 
ordered by the relation FALSE < TRUE. 


Values of symbloc, reference, row or plex type are not ordered and can only 


~be compared for equality and inequality. 


Values of array elements or slices can be compared for equality and ine- 
quality. In addition, if an order relation exists for the type of the array 
elements, then the relational operators <, >, <= and >= are applicable and 
serve to test for the lexicographical order of slice values. 


Note : 


If A and B are arrays, R and S rows, then R=S is a Biation between row 
values whereas R.VALUE=S.VALUE, or equivalently, 
R(FIRST..LAST)=S(FIRST..LAST) are slice relations. The relation A=B is not 
permitted and must be written as A/F/RST..LAST) = B(FIRST..LAST). 


The semantics of row comparisons is given in 4-2.3.8. 


The first form of membership relation is used to test whether a symbolic 
variable belongs to a given symbolic range ; similarly, whether an integer 
variable belongs to a discrete integer type. 


The second form is used to test whether a discrete simple. expression 
pelonge to a set simple expression. 


The binary adding operators + and - can be applied to operands of integer 
type and deliver an integer result. 


The adding operators OR and XOA can be applied to epeeande which are 
both of boolean type or of the same set type. It delivers a result of the same 
type as the operands. The operator OA represents the /ogica/ inclusive or for 
boolean operands, the inclusive union for set operands. The operator XOR 
represents the /ogical exclusive or for boolean Operators: the exclusive union 

for set operands. , 


4-2.3.4. Multiplying operators 


4-2.3.5. Unary operators 


4-2.3.6. The operator REF 


4-2.3.7. The operator ROW 


4-2.3.8.. Row comparison 


Expressions 


The multiplying operators x, ‘and MODULO can be applied to operands of - 
type integer and deliver an integer result. The operator * represents the mul- 
tiplication. The operator / has the meaning of integer division. The operator 
MODULO is defined in the following way : 


X MODULO Y = X - (( X/Y ) x Y) 


The multiplying operator AND can be applied to operands which are both of 
boolean type or of the same set type. It delivers a result of the same type as 
the operands. Its meaning is that of the /ogica/ and for boolean operands ; 
set intersection for operands of a set type. 


The operators + and - may be used as unary operators with an integer 
operand and deliver an integer result. The unary operator - inverts the sign of 
the operand, the unary operator + delivers the absolute value of the 
operand. 


The unary operator NOT can be applied to a boolean operand or to an 
operand of a set type. For a boolean operand it delivers a boolean result 
which is the logical negation of the operand. For a set operand it delivers a 
result of the same set type. This result is the set complement of the operand. 


The operator REF can be applied to an operand which is a primary of type 
plex. It delivers a result which is a reference to the plex obtained by evalua- 
tion of the primary. 


The operator ROW can be applied to an operand which is a primary of array 
type or a slice. It delivers a result which is a row pointing to that array or 
slice. 


If A is an array with a symbolic type 7 as index nature, then the factor ROW 
A is equivalent to the factor ROW A/T). 


If B is an array with a discrete integer index nature, then the factor ROW B is 
equivalent to ROW B(FIRST..LAST). 


The result of the ROW operation is defined as folows : 
(a) ROW A/T) delivers a row. which designates the slice A(7). 


(b) ROW BiI..J) 
delivers a row with the following attributes 
— FIRST is equal to O (by convention) 
_— LAST is equal toJ—/ | 
— BASE designates the element B//). 


~The result of the row operation may be compared with or assigned to 
another row (see 4-2.3.8. and 5-1.3.2.). 


Two rows are equal if and only if they designate the same array or the same 


slice. 


For rows with a discrete integer index, the row equality R=S is equivalent to 
the following conditions on the row attributes : 


(a) R. LAST — R. FIRST = S.LAST — S. FIRST 
The slices designated contain the same number of elements. 


(b} R.BASE and S.BASE must be such that AR(F/RST) and S(FIRST) 
designate the same element. If & designates the size of the elements, 
this (machine dependent) condition may be expressed as follows: 


R.BASE + E * R.FIRST = S. BASE + E x S. FIRST 
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4-3. Set primaries 


4-3.1 . Syntax 


4-3.2. Examples 


 4-3.3. Semantics | 
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<set primary> «= 
SET (<type name> ) 
! SET ( <interval> ) 
! SET (<sequence of expressions» ) 


<sequence of expressions > == 
<sequence of expressions» | <expression> 
! expression» 


SET ( COLOR ) 

SET (WARM ) 

SET ( COLD ) 

SET ( SHADE | BLACK | ORANGE ) 
SET (8/9|10) 

SET (1..J) 


A set primary is used to build a set value. 


The form SET (<type name>), where <type name> is the name of either a 
discrete type or a symbolic range, denotes a set Containing all the values of - 
the discrete type or of the symbolic range. The discrete type mentioned (or 
the discrete type containing the symbolic subrange) is the base type of the 
set type of the primary. 


The form SET (<interval>) denotes a set containing all the values of the in- 
terval. Its type is context dependent. 


Three cases must be considered for set primaries containing a sequence of 
expressions. 


(a) Sequence of symbolic expressions : 
All expressions must be of a same symbolic type which is taken as the 
base type of the set type of the primary. 


(b) Sequence of integer expressions : 
The set type of the primary must be determinable from its left context. 
For example, in an assignment such as 


S := SET(I|J|K): 


the base type of the set primary is the base type of the set variable S. On 
the other hand the relation 


SET (| J) < SET(9]10/Y) 


is not legal since there is no way to determine the base type of the two 
set primaries. 


(c) SET (N/L) denotes an empty set; its type is context dependent. 


4-4. Aggregate primaries 


4-4.1. Syntax 


4-4.2. Examples 


4-4.3. Semantics 


Expressions 


< aggregate primary > «= 
( <sequence of intializations> ) 
! <character string> 


<sequence of initializations> == 
<sequence of initializations> , <item initialization > 
! <item initialization> 


<item initialization> == 
<variable denotation > <initialization> 
| <label part> <initialization> 


Array initialized with an array aggregate primary : 


EXPIRATION : ARRAY ( 1..20 ) OF DATE == 
fe Vice > == (DAY ==10,MONTH== 1, YEAR== 1940), 
<6> == (DAY == 20, MONTH == __ 1, YEAR == 1960), 
< OTHERS >==(DAY== 3, MONTH == 12, YEAR == 2000 )) ; 


Plex aggregate primary in an ALLOCATE statement : 


ALLOCATE DEVICE == 
( UNIT == DISK,STATUS == SET (NIL),CYLINDER == 1, TRACK == = 1) 


Character string : 
"FOR OTHER EXAMPLES SEE SECTION 2-3.5.’ 


Aggregate primaries serve to build plex values and array values. An item. 


initialization may take two forms. The form <variable denotation> 


<initialization> defines the value of an attribute of a plex. In the second 
form, each label represents the index of an array element and the initializa- 
tion is used to define the value of the element (or elements). All item in- 
itializations of a sequence of item initializations must be of the same form. 


The (array or plex) type of an aggregate primary must be determinable from 
its left context. Thus in the first example of 4-4.2., the possible label values, 
and hence the values represented by OTHERS are known from the fact that 
the aggregate primary is used to initialize the array EXP/RATION. Similarly 
in the allocate statement the type of the aggregate primary is derived from 
the declaration of the variable DEV/CE. Without this context the attributes 
UNIT,...,.TRACK (see examples of 3-3.2.) would be unknown. For the same 
reason a relation such as 


(DAY == X, MONTH == Y,YEAR == Z)=(DAY==L,MONTH == M, YEAR == N) 
is not legal. 


A character string is an aggregate primary of type array of character (see 2- 
3:5,.1.). 


An aggregate primary must provide values for all the attributes or elements 
of the plex or array considered. The only possible exception is for plex 


_ aggregate primaries used in an initialization (i.e. either in a declaration or in 


an allocate statement (see 5-10.)). 
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5-0. Sisioments and statement lists 


| 5. Statements 


Cn ee 


-<connection statement> 


aesignment statement) 


<if statement) - 
<case statement») 
<loop statement) 
<loop exit statement> 
<subprogram call> 


-Creturn statement — 


<with statement» 

allocate statement) 

<free statement> 

<symbolic output statement> 


~ NULL 


<statement list) s= 


<statement list> <statement) ; 
<statement> ; 


Statements define the execution of the algorithms. Statements following . 
one another in a statement list are executed sequentially. The execution of a 
statement list may however be shortened if one of the statements is a loop 
exit statement or a return statement. 


If, case, loop, and with statement are called compound statements. Their 
definition includes one or more lists of statements which can themselves be 
compound or not. 


The keyword NULL stands for a null statement. 
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5-1. Assignment statements 


5-1.1. Syntax 


5-1.2. Examples 


5-1.3. Semantics 


5-1.3.1. Reference assignments 


<assignment statement> «= 
<variable denotation> := <expression> — 


SHADE := BLUE; 
TODAY. DAY := TODAY. DAY + 1; 


_ TITLE(10) :='A'; a 
_ INPUTUNIT. STATUS := SET( OPEN| FIXED); 


Reference assignments : 


ANCESTOR := COUSIN .FATHER. FATHER ; 

UNCLE := COUSIN. FATHER ; : 
LEFTCAR := RIGHTCAR ; 

UNIT := REF INPUTUNIT ; 


Row assignments : 


ROWONE :=ROWTWO;; . 
PASSWORD := ROW TITLE; 
PASSWORD := ROW ‘MY NAME IS JULES’ ; 


Slice assignments : 


TITLE (10..20):= PASSWORD (1..J); 

TITLE (30..40):= ‘NEW SECTION’ ; 

UTILITY (1..9):= UTILITY (10..19); 

ROWONE (FIRST... LAST) := ROWTWO (FIRST.. LAST); 


Plex assignments : 


(NPUTUNIT := OUTPUTUNIT : 


ME := COUSIN. VALUE ; 
TODAY := (DAY ==.11, MONTH == 1, YEAR == 1984); 
EXPIRATION (J):= TODAY; 


An assignment statement serves to replace the current value of a variable by 
a new value specified as an expression. The variable and the expression 
must be of same type, with the following exceptions being permitted : 


(a) the type of the variable is reference to a plex type, and the type of the 
expression is reference to a domain of the same plex type. 


(b) the value of an expression of discrete integer (or index) type may be 
assigned to a variable of a different discrete integer (or index) type if this 
value is in the range of the latter type. Optionally, run-time range checks 
may be generated by the compiler. 


A reference assignment such as X := AEF Y is not allowed if the life-time of 
the reference variable X longer than the life-time of the plex variable Y (see 
3-0.3.1. Life-time). This restriction is meant to avoid the possibility for X to 
refer to a plex variable which has no longer any meaning (ghost). 


A variable which is a reference constant can only be assigned to another 
reference constant. 


' Statements 


5-1.3.2. Row assignments 


5-1.3.3. Slice assignments 


A row assignment A :=S is only allowed if the element types of the two 


_ rows are identical. 


If the index nature of the row A is a symbolic type, the index nature of S 
must be the same symbolic type. After the assignment, AR and S designate 
the same array. 


If the index nature of the row A is a discrete integer type, the effect of the 
row assignment is defined in terms of assignments to the row attributes 
R.LAST andR. BASE (R . FIRST wen isa static Integer. COnstant & remains 
unchanged) : 


(a) R.LAST:=R.FIRST + (S.LAST-S.FIRST) 
(b) R.BASE is modified so as to designate the element R/O), whether this 
element is real or virtual. 


In other words, after the row assignment R:=S, R(FIRST..LAST) and 
S(FIRST..LAST) designate the same slice. EATS a 


Examples : 


A : ARRAY (O.. 100) OF INTEGER : 
_R:ROW (0.. 100) OF INTEGER ; 
T : ROW (1...80) OF INTEGER ; 


After the assignment R:=ROW A/(10..30) we have R.LAST=20 and 
R.BASE designates A/10). Since R.FIRST=O we have : 


R(O) is A(10) , ..., R(20) is A(3O). 


After the subsequent assignment 7:=A, we have 7.LAST=27 and 
7T.BASE designates A(9). Since 7.F/IRST=1 we have: 


T(1) and R(O) are A(10),..., T(21) and R(20) are A(30). 


Both the variable denotation and the expression of a slice assignment must 
be slices of arrays having the same element type. 


If the arrays have a symbolic index nature, the slices must indicate the same 
symbolic subrange. The slice assignment is equivalent to an element by ele- 
ment assignment for indexes ranging over the symbolic subrange. 


A slice assignment AR//:M):=S(/:N) must satisfy the condition M<N. 
This is always true for assignments of the form Af/: *):= S(J:N) or 
R(l: M) := S(J: x), since the ‘’*" is understood as the length of the slice of 
the other side of the assignment. 


The above slice assignment is equivalent to the sequence of element 
assignments : 


R(l + L) := S(J + L) for L= O,...,M-1 


In addition, for each element assignment, S(/+L) must not designate an 
element of the slice A//:M) already modified in the slice assignment. In 
other words, if the two strings overlap, i.e., if for some Z there is an index K 
such that A(/+K) and S{/J+L) designate the same element, then we must 
have K>L. 


Notes: 


If A and B are arrays, R and S rows then 


A(FIRST .. LAST) := B(I.. J); 
R(X... Y¥) := S(l.. J); 
S(M..N) :=A(E.. F): 


are slice assignments. On the other hand A := S and R := ROWA are row 
assignments. The notation A := 8 is not accepted. In order to assign all the 
elements of 8B to those of A the slice assignment 
A(FIRST..LAST) := B(FIRST..LAST) must be used. 
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5-1.3.4. Plex assignments 


5-1.3.5. Assignment to a selector 


5-2. Connection statements 


5-1. Syntax 


‘5-2.2. Example 


5-2.3. Semantics 


A plex assignment assigns a plex value to a plex of the same type. 
A plex of a domain cannot appear at the left of a plex assignment. 
After an assignment to a selector, all attributes whose existence depend on 


the selector value have an undefined value. The assignment is not valid if the 
plex belongs to a domain. 


<connection statement) «= 


<program denotation> := ACTION <program denotation> 


OPERATOR := ACTION INTPOWER ; 


A connection statement sets the subprogram which must be executed for 
calls of a connector. The denotation of the connector ‘is on the left of the 
connection statement. The subprogram assigned to the connector must be 
one of the subprograms mentioned in the connector declaration. 


5-3. If statements 


5-3.1. Syntax - 


5-3.2. Examples 


5-3.3. Semantics 


Cif statement> «= 


<true part) <else part> END 
 <true part» END 


ee part > s= 
<true part» <elsif part> 
| <if part> 


Cif part> == | 
IF <expression> THEN <statement list> 


<elsif part) «= 
ELSIF <expression> THEN <statement list) 


<else part) == 
ELSE <statement list> 


\F OUTPUTUNIT. UNIT = PEINVERTBEN 
DELETE ; 
END; 


IF MONTH >= 12 THEN 
MONTH :=1; 
YEAR : = YEAR +1; 

ELSE 
MONTH := MONTH + 1; 

END; 


1F SI IN OPTIONS THEN 
INPUTFORMAT := SYMBOLIC ; 
ELSIF Ci IN OPTIONS THEN 
INFUTFORMAT : = COMPRESSED ; 
ELSE 
ERROR ; 
END; 


Expressions 


The execution of an if statement proceeds as follows. The conditions 
(boolean expressions) of the if part and of the subsequent elsif parts are 
evaluated one by one. Evaluations are stopped as soon as a JRUE condition 


is encountered. 


The execution of the statement list of the corresponding if or elsif part then 


completes the execution of the if statement. 


If, on the other hand, all the conditions evaluated « are FALSE the execution 
of the statement list of the else part (if any) completes the execution of the if 


statement. 


Al 
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5-4. Case statements 


5-4.1. Syntax <case statement> == 
< case’ statement hands <alternative list> END 


alternative list> «= 
alternative list> <alternative> 
1 alternative» 


<case statement head» «= 
_ CASE <simple eee OF 
! CASE <simple expression> IN <type name> OF 


alternative > == 
<label part) : <statement ny : 


N 


5-4.2. Examples CASE SURRENTIOL NRE OF 
<PROCED> : 
IF CURRENTID. PARANUM /=0 THEN 
UPDATE (NUM :=: CURRENTID.PARANUM) ; 
END; 
CURRENTID . DATAADDRESS :=0: 


<TABLE>: 
CURRENTID . INDEX := 1; 


<VARIABLE> : 
DELETE ; 
OUT SHADE, LINE, CURRENTID.ADDRESS, PAGE ; 
END; 


CASE TRAPCAUSE OF 
<NI>: 
PRINT (MESSAGE := ROW ‘INEXISTING STATEMENT ' ) ; 
<MPV> : 
PRINT (MESSAGE := ROW ’VIOLATION OF PROTECTION’); 
<OTHERS> : 
NULL ; 
END: 


CASE SHADE IN COLD OF 
<GREEN> : 
NULL; 
<BLUE| BLACK>: 
~ SHADE := GREEN ; 
END ; 


5-4.3. Semantics A case statement is used to execute the statement list of one of its 


alternatives chosen on the basis of the value of the expression which 
appears in the case statement head (the case statement selector). 


The alternative chosen is the one whose label part includes the value of the 
selector. 


The selector must belong to a discrete type and each value of this type must 
appear in one and only one label part of the case statement (see 3-3.3.2.). 


A case statement may be restricted to the values of a symbolic range men- 
tioned in the case statement head. If the value of the case selector does not 
belong to the symbolic range, the case statement is equivalent to a null 
statement. } 


Expressions 


a a 


5-5. Loop statements ae Ze . 


5-5.1. | Syntax 


5-5.2. Examples 


5-5.3. Semantics 


<loop statement> = 
<basic loop> 
| iteration condition> <basic loop> 
! <basic loop> <iteration condition> 


<basic loop> = 
LOOP <loop label part> :<statement list> REPEAT 
! LOOP <statement list> REPEAT 


<loop label part > s= 
< <identifier> >. 


<iteration condition> #= 
WHILE <expression> 
! UNTIL <expression> 
! FOR <identifier> := <iteration range» 


<iteration range> == 
EACH <type name> 
| <expression> TO <expression> 
| <expression> DOWNTO <expression> 


LOOP <FINDANCESTOR?> : 
EXIT <FINDANCESTOR> IF KINSMAN = NIL; 
ANCESTOR := KINSMAN ; 
KINSMAN := KINSMAN. FATHER ; 

REPEAT ; 


WHILE KINSMAN /= NIL LOOP 
ANCESTOR := KINSMAN ; 
KINSMAN := KINSMAN. FATHER ; 

REPEAT ; 


LOOP 
UPDATE (NUM :=:1); 
REPEAT UNTIL | >= 10; 


FOR CHOICE := EACH COLOR LOOP 
IF CHOICE /= INVERSE ( CHOICE ) THEN 
MIX.:= MIX OR SET (CHOICE): 
END; 
REPEAT ; 


FOR |1:=1 TO 100 LOOP 
IF A( 1) > MAX THEN 
MAX :=A(1); 
END: 
REPEAT ; 


A loop statement specifies that the list of statement of the basic loop is to 
be executed repeatedly. The number of iterations may depend on an itera- 


- tion condition. 


If no iteration condition is given, the execution of the basic loop can only be 
stopped by a loop exit statement. 


The loop name defined by a loop label part is only visible whithin the loop 
considered. It can be mentioned in a loop exit statement (see 5-6.). 
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5-5.3.1. WHILE and UNTIL iteration conditions 


5-5.3.2. FOR iteration condition 


5-5.3.3. 


AA 


Iteration ranges 


The expression which appears in a WHI/LE or UNTIL iteration condition must 
be a boolean expression. In the case of a WH/LE condition, the iterations go 
on as long as the expression yields the value TRUE. The iteration condition 
UNTIL <expression> is equivalent to the iteration condition WH/LE NOT 
< expression). 


An iteration condition which appears textually before a basic loop is 


_ evaluated before each iteration. As a consequence the basic loop may in 


some cases not be executed at all. 


“An iteration condition which appears textually after a basic loop is evaluated 


at the end of each iteration. As a consequence the basic loop will always be 
executed at least once. 


A FOR iteration condition consists of an identifier (the control variable) and 
of an iteration range which specifies the values which must be assigned to 
the control variable for the successive iterations. 


The control variable is implicitly declared by its occurence within the FOR 
iteration condition. Its type is that of the elements of the iteration range. It is 
only visible within the loop and must be considered as a constant within the 
basic loop (between LOOP and REPEAT). Therefore it cannot appear on the 
left hand side of an assignment, or be passed as result parameter within the 
basic loop. 


A FOR iteration condition can only be placed textually before a basic loop. 


The expressions (if any) which appear in iteration ranges are evaluated only 
once, at the beginning of the execution of the loop statement. Three cases 
must be considered : 


(a) EACH <type name> 


The type name must be that of a discrete type (either integer or sym- 

- bolic). At each iteration, a different value of the discrete type is assigned 
to the control variable. The iterations stop when all values of the discrete 
type have been assigned. The order! in which these assignments are per- 
formed is undefined. . 


(b 


— 


<expression> TO <expression > 
The two expressions must be of integer type. The FOR loop 
FOR |:=L TO R LOOP 


<statement list> 
REPEAT ; 


has the same effect as: 

[sb 

WHILE | <= R LOOP 
<statement list> 
Meta Um ae 

REPEAT ; 


5-6. Loop exit statements 


5-6.1. Syntax 


5-6.2. Examples 


5-6.3. Semantics 


‘ a ~ -. Expressions 


(c) <expression> DOWNTO <expression> 


The two expressions must be of integer type. The FOR bab 
FOR |:=L DOWNTO R LOOP 

<statement list 
REPEAT ; 


has the same effect as | 

bs Be 

WHILE | >= R LOOP 
<statement list> 
}:=1-1; 

REPEAT ; 


Note: 


For iteration ranges of the form (b) or (c) the type of the control variable is 


index if one (or both) of the expressions are of (the same) index type. 


<loop exit statement) == 
EXIT < <loop name> >IF Gomprespion? 
! EXIT IF <expression> 
! EXIT < <loop name> > 
| EXIT. 


EXIT; 


EXIT <FINDANCESTOR> ; 
EXIT <FINDANCESTOR> IF KINSMAN = NIL; 
EXIT IF TODAY.YEAR = 2000 ; 


A loop exit statement terminates the execution of a loop. Two cases should 
be considered : 


(a) If the exit statement mentions a loop name, the exit refers to the cor- 
_ responding loop. 


(b) If the exit statement does not mention a loop name, the exit refers to the 
loop immediately enclosing the exit statement. 


Exit statements which include the keyword /F followed by an expression 
(which must be of boolean type) are executed only if the evaluation of the 
expression yields the value 7RUE. The other forms of exit statements are ex- 
ecuted unconditionally. 
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5-7. Subprogram calls 


5-7.1. Syntax 


5-7.2. Examples 


_5-7.3. Semantics 


5-7.3.1. Parameter assignments 
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<subprogram call> «= 
<program denotation> ( <sequence of parameter assignments > ) 
! <program denotation> ( <expression> ) 
! <program denotation> 


<sequence of parameter assignments» «= 
<sequence of parameter assignments» , <parameter assignment» 
! <parameter assignment») 


* <parameter assignment) == 


<value parameter assignment> 
! <result parameter assignment» 
! <value result parameter assignment> 


<value parameter assignment) == 
<formal parameter> := <expression> 


<result parameter assignment> «= 
<formal parameter> =: «variable denotation> 


<value result parameter assignment) «= 
<formal parameter> :=: <variable denotation> 


<formal parameter > «= 
<variable > 


DELETE ; 
CONVERT (1D := CURRENTDESCRIPTOR } ; 
CONVERT ( CURRENTDESCRIPTOR ) ; 


Value parameter assignments : 


SETDCB ( OPL:= ROW’EI’, ORG := PARTITIONED, 
REL := 80, KYL:=6, KYP:=0); 
PRINT ( MESSAGE := ROW’INCORRECT ALIGNMENT ) ; 


Result parameter assignment : 
CREATE ( NEWELEMENT =: DEVICE) ; 
Value result parameter assignment : 
UPDATE (NUM :=:X); 


A subprogram call is used to execute the program body of a subprogram. 
This execution may be preceded and/or followed by parameter 
assignments. 


Action and procedure calls differ by the nature of the memory allocation for 
their local data (see 3-8.3.1.). Coroutine calls have special semantics (see 5- 
7.3.3.). 


A formal parameter of a subprogram is local to that subprogram. Within a 
program body, a formal parameter can be used in the same way as a 
variable of the same type. A formal parameter name may also appear in a 
parameter assignment. A parameter assignment may be used to assign the 
value of an actual parameter to a formal parameter, and/or to return the 
value of a formal parameter to an actual parameter. 


An actual parameter may be a variable denotation or an expression and 
must be visible at the place of the subprogram call. 


Expressions 


5-7.3.2. Rules for parameter assignments 


5-7.3.3. Couroutine calls 


There are three forms of parameter assignments : 
(a) Value parameter assignment : 


The formal parameter mode must be /N or /N OUT. The assignment of 
the actual parameter to the formal parameter is made prior to the execu- 
tion of the subprogram. 


(b) Result parameter assignment : 


The formal parameter mode must be OUT. The execution of the sub- 
program is followed by the assignment of the formal parameter to the 
actual parameter. 


(c) Value-result parameter. assignment : 


The formal parameter mode must be /N OUT. This form combines the 
preassignment of the value form and the post assignment of the result 
form. 


Value parameter assignments are used for optional parameters and for calls 
of the form<subprogram)> (<expression)). 


The type of each actual parameter must agree with that of the 
corresponding formal parameter as for an assignment statement (see 5-1.). 


Each call must include parameter assignment for all formal parameters. The 
only exception is for default parameters : if the formal parameter definition 
includes an initialization, its value is implicitly used as actual parameter 
when no explicit parameter assignment is provided. 


The meaning of a subprogram must remain invariant for permutations of 
parameter assignments. As a consequence the subprogram calls which 
follow are illegal : 


P(A=:1,B=:1): 
P(A=:l1, B=:T(1)); 


Two kinds of calls should be distinguished : 


(a) Call of a coroutine by the enclosing program. 
The effect of such a call is to: 


— position the outer point after the call, 

— initialize the coroutine family, 

— begin the execution of the called coroutine starting from its local 
point. 


(b) Call of a couroutine by another coroutine of the family. 
The effect of such a call is to: 


— position the local point of the calling coroutine after the call, 
— begin the execution of the called coroutine starting from its local 
point. 


Only value parameters are allowed ; parameter assignments are performed 
prior to the coroutine call. 


The initialization of a coroutine family positions the local point of each cor- 


outine of the family at the beginning of its body, (where applicable, before 
the initializations of data local to the coroutine). 


A coroutine cannot be called by a procedure which is local to another cor- 
outine. 
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5-8. Return statements 


5-8.1. Syntax 


7 5-8.2. Examples : 


5-8.3. Semantics 


5-9. With statements _ 


~5-9.1. Syntax 


5-9.2. Examples 


-5-9.3. Semantics 
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<return statement) «= 
RETURN <expression > 
! RETURN 
! RETURN FROM <program fants 


RETURN ; 
RETURN A + B; 


RETURN FROM SCANNER ; 


A return statement terminates the execution of a subprogram. A program 
name may be explicitly mentioned by a return statement provided that the 
latter appears within the program body of the subprogram mentioned. When 
no name is mentioned, the subprogram terminated is the subprogram 
whose program body is immediately outer to the return statement. 


A return statement from a function includes an expression whose value is 
the result of the evaluation of the function. In order to avoid side-effects in 
functions, a return statement executed in a function cannot mention the 
name of a subprogram outer to the function. 


The execution of a return statement which is textually within the program 
body of a coroutine restarts the execution of the enclosing program at the 
outer point. Therefore, it is a return to the enclosing program, and not a 
return to the calling coroutine. 


<with statement> «= 
WITH <item initialization> DO <statement list) END 


<item initialization> == 


<identifier> <initialization> 


WITH C == CURRENTIDENT DO 
C.KIND := REAL; 
IF C. NATURE = PROCED THEN 
C.PARANUM :=0O; 
END: 
END ; 
WITH THIS == KINSMAN. FATHER . FATHER DO 
IF THIS. BIRTH > 1850 THEN 
THIS . GETAGE (AGE :=X); 
END; 
END ; 


A with statement defines a constant reference (or a plex) which is visible 
within the statement list of the with statement. The constant reference (or 
the plex) is implicitly declared by its occurence after the keyword W/TH. Its 
type is that of the expression (necessarily of type reference, index or plex) 
which appears before the keyword DO. 


With statements are used to simplify notations when several accesses are 
made to attributes of a given plex. 


Expressions 


5-10. Allocate and free statements 


5-10.1. Syntax 


5-10.2. Examples 


5-10.3. Semantics 


<allocate statement> «= 
ALLOCATE <variable denotation> <initialization> 
! ALLOCATE <variable denotation> 


<free statement> #= 
FREE <variable denotation> 


ALLOCATE COUSIN ; 

ALLOCATE COUSIN == ( FATHER == UNCLE) ; 
ALLOCATE ONE DEVICE ==( UNIT == DISK, STATUS == SET (OPEN)); 
FREE COUSIN. FATHER ; 
FREE COUSIN ; 


The statements allocate and free are used to allocate and free plexes. The 
variable denotations which appear in these statements must be reference 
variables, bound to the domain where the allocation must be, performed (or 
to which the plex must be returned). More precisely, if X is of type REF D, 
the statement ALLOCATE X performs an allocation in the domain D. 


If an initialization is provided in the form of an aggregate primary, it is 
evaluated first and serves to establish the length of the plex allocated. For 
plexes with variable parts, the length of the plex will depend on the actual 
values given to the selectors. For missing selectors, the maximum length for 
the corresponding variable part is used. 


The second step of the execution of the allocate statement is a call of the ac- 
tion ALLOCATE defined in the implementation schema used for the domain 
considered. The variable denotation which appears in the allocate statement 
is used as result parameter for this action and a reference to the newly 
created plex is returned in this parameter. 


Finally, the attributes mentioned in the initialization are initialized with the 
values computed in the initial step. 


A free statement frees the plex referenced by the variable denotation. The 
latter becomes equal to N/L. This effect is achieved by calling the action 
FREE defined in the implementation schema used for the domain con- 
sidered. The variable denotation is used as value parameter for this action. 


See section 7-7. for domain implementations. 
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5-11. Symbolic output statements 


5-11.1. Syntax 


5-11.2. Examples 


5-1 1.3. : Semantics 
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<symbolic output statement) == 
<symbolic output statement») , <symbolic output element> 
! OUT <symbolic output element> - 


<symbolic output element> «= 
< expression > 
! TO <simple expression> 
! LINE <simple expression> 
! LINE 
! PAGE 


OUT ‘TRAPCAUSE :’, TRAPCAUSE,LINE ; 
OUT ‘| = ’, I, LINE, ‘J =’, J, LINE; 
OUT TO 15, I, TO 30, A (1); 


Symbolic output statements are used to print the values of variables and 
arrays in a symbolic form. For a symbolic variable, it is the symbolic value 
(not the internal code) which is printed. Symbolic output of an array of 
characters prints the corresponding sequence of characters. Symbolic out- 
puts of other arrays produce the positions and the symbolic outputs of the 
elements. Symbolic output of a plex is not possible. . 


The sequence of characters representing a symbolic output element is 
copied into a compiler maintained internal buffer, starting at the current 
position in the buffer. This current position is then incremented by the 
number of characters in the sequence. 


The current position may be set explicitly by an element of the form 7O 
<simple expression>. A line is printed if the new position is smaller than the 
old current position. 


In general, printing occurs when the current element does not fit in the 
remaining buffer space or when the keywords L/NE or PAGE are en- 
countered. The current position is then reset to one. 


A symbolic output element of the form L/NE <simple expression> skips the 
number of lines given by the simple expression. The elements L/NE and 
LINE O cause a skip to the next line. The element PAGE ejects one page. 


Example : 
The first two OUT statements may print the following lines : 


TRAPCAUSE : MPV 
1= 100 
J= 200 


On the other hand, the output of the third statement will remain in the 
internal buffer until the line is filled. 
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6-0. Informal introduction | 


6-0.1. Programs and subprograms 


6-0.2. Compilation units 


6-0.3. Visibility and Scope 


6. Visibility and general program structure 


A LIS program normally contains several subprograms. Seen individually, 
these may also be viewed as programs, and they may in turn contajn other 
subprograms. Hence, the terms program and subprogram will often be used 
interchangeably in what follows. The term program will be used when the 
attention is on the program itself; the term subprogram, when it is con- 
sidered as a part of a larger (sub)program. 


A LIS program as a whole (a program which is not contained by any other 
subprogram) is generally made of a collection of compilation units, that is, of 
parts which are separately compilable. 


A compilation unit may consist of a single subprogram and is then called a 
program segment. Conversely, subprograms which are not segments are 
often referred to as internal subprograms. . 


The declarations made in a program segment may be separated from the 
latter to form another compilation unit, called a data segment. Both the 
program segment and its associated data segment bear the same name, 
namely, that of the subprogram which together they represent. 


Data partitions and program partitions are the two other forms of compila- 
tion units. A data partition is a group of declarations. It may be-viewed as a 
separately compiled section of a data segment. A program partition is a 
group of program bodies which are compiled together, as one compilation 
unit. 


Data and program partitions will often be created in the process of splitting 
a program segment into smaller compilation units. Hence the name par- 
tition. 


The internal subprograms and the compilation units which form a LIS 
program are hierarchically organized. For internal subprograms the hierarchy 
is. based on.the textual nesting of their bodies. For compilation units, it is 
based on the position of segment and partition declarations and on other 
specific rules (see 6-3.3. and 6-4.3.). . 


An important notion associated with this hierarchy is the notion of visibility. 
An identifier is said to be visible at a given program point if the program 
hierarchy is such that a declaration applicable to that identifier can be found. 
The properties of the identifier, namely, its nature and its type are then those 


. which are defined by the declaration. 


Conversely, the scope of the declaration of a given identifier is said to extend 
to all program points where this identifier is visible and has the properties 
defined in the declaration considered. 


In the following sections the rules which govern visibility in internal sub- 
programs and across compilation units will be examined. 


mod 


4549 E 


The system implementation language LIS 


6-1. Program bodies and visibility 


6-1.1. Syntax <program body > «= 
<program head» <declarative part> <block> 
! <program head> <block> 


<program head> == 
PROGRAM <program denotation> ; 


<declarative part) == 
<declaration list> <list of program bodies» 
! <declaration list> 
! <list of program bodies» 


<declaration list) == 
<sequence of declarations ; 


<sequence of declarations> «= 
<sequence of declarations» ; <declaration> 
! <declaration> 


<list of program bodies)» «= 
<list of program bodies» program body > ; 
! <program body» ; 


<block> s= 
BEGIN <statement list) END 


6-1.2. Examples PROGRAM SORT ; 
VECTOR : ARRAY (1.. MAX) OF INTEGER ; 
LIMIT : INTEGER ; 
NOSWAP : BOOLEAN ; 
SWAP : ACTION (J: IN REF VECTOR ); 


PROGRAM SWAP ; 
TEMP : INTEGER ; 
BEGIN 
TEMP := VECTOR( J); 
VECTOR( J) := VECTOR(J+ 1); 
VECTOR(J +1) :=TEMP ; 
END; $ SWAP $ 
BEGIN 
LIMIT := VECTOR.LAST ; 
LOOP 
NOSWAP := TRUE; 
LIMIT := LIMIT - 1 ; 
FOR | :=VECTOR.FIRST TO LIMIT LOOP 
— IF VECTOR(1) < VECTOR (1 + 1) THEN 
SWAP (1); 
. NOSWAP := FALSE ; 
END; 
-REPEAT ; 


REPEAT UNTIL NOSWAP OR (LIMIT <= VECTOR.FIRST } ; 


END; $ SORT $ 


92) 


6-1.3. Semantics - 


6-1.3.1. Annotated example 


Visibility and general program structure 


_ In US the text of a subprogram declaration (defining its name, nature and 
type, as. well as those of its parameters) and the text of the corresponding 


program body generally appear separately. The program body contains a 
block, and possibly also a declarative part. Items declared in the latter: are 
said to be /oca/ to the subprogram. 


lf a declarative part contains declarations of local subprograms, it must also 
contain their program bodies. As a consequence, the program bodies of in- 
ternal subprograms may be nested. 


Let A be a subprogram, and B another subprogram local to A. The program 
body of B is said to be /nner to that.of A. Conversely, the program body of A 
is said to be outer to that of B. An item declared in a program body which is 
outer to B is said to be g/obal/ to B. 


The visibility rule applicable in such a nested program structure is as 
follows : An identifier declared in a given program body is visible in this — 
program body and in all program bodies inner to the one considered. 
Conversely, the identifiers which are visible in a given program body are 
those which are declared in this program body or in program bodies outer to 
the one considered. 


These notions are illustrated in the following example. 


A: ACTION ; Locality: 
PROGRAM A; — 1,J,B,C are local to A 
|, J: INTEGER: — K,D,E are local to B 
B, C: ACTION; — L is local to C 
PROGRAM 8: eer 
K: INTEGER; | 
D, E: ACTION ; 
PROGRAM D; 
M : INTEGER ; 
BEGIN 7 
block of D Inner or outer: 
END; 
— B,C and D,E are inner to A (A is outer to B,C,D,E) 
PROGRAM E;; _ — D,E are inner to B (B is outer to D,E) - ' 
N: INTEGER - ‘— C is neither inner nor outer to B,D or E 
BEGIN ~ D is neither inner nor outer to E 
block of E 
END: - 
BEGIN 
block of B 
END; 
PROGRAM C: 
L INTEGER ; Identifiers visible in the program bodies: 
BEGIN . 
block of C Program body of A:A, 1, J, B, C 
END; Program body of B :A,1, J, B, C, K, D, E 
BEGIN Program body of C:A,1, J, B,C, L 
block of A Program body of D:A, I, J, B,C, K, D, E, M 
END: Program body of E :A, I, J, B, C, K, D, E, N 
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6-1.3.2. Unique visibility restriction The following restriction exists for the visibility rule given in 6-1.3. : At each 


6-1.3.3. Visibility of Symbols 


6-1.3.4. Visibility of attributes 
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program point, only one declaration may be applicable to a visible identifier. 
In other words, an identifier declared local to a subprogram A cannot be 
redeclared in a program 8B inner to A, with the effect of masking the outer 
declaration. 


This restriction does not forbid the redeclaration of an identifier declared 
PRIVATE in an outer program, since the scope of private identifiers does not 
extend to inner programs. Neither does it forbid the declaration of the same 
identifier in two programs which are not nested. Thus, the two declarations 
of / in the example below are compatible 


‘PROGRAM A: 


B,C : ACTION ; 


PROGRAM B; 
|: BOOLEAN : 
BEGIN 


END ;: 
PROGRAM C: 

|: INTEGER: 
BEGIN 


END: 
BEGIN 


END; _ 
see also 6-4.3.1., note (b). | 


The symbols which appear in the definition of a symbolic type are visible at 
any program point where this definition is visible. 


If a symbolic type is defined within a plex type definition (or within a 
parameter declaration of a subprogram), its symbols are visible at any 
program point where the plex type definition (or the subprogram name) is: 
visible. 


Attributes are visible within the declaration of the plex type to which they 
belong. They are also visible in indirect names (see 4-1.3.1.), in aggregate 
primaries (see 4-4.), and in the program bodies of attribute subprograms of- 
the plex type considered (see 3-3.3.3.). 


6-2. Separate Compilations 


6-2.1. Syntax 


6-2.2. Examples 


6-2.3. Semantics 


Visibility and general program structure 


<compilation> = 
<compilation> <compilation unit> ; 
! <context> <compilation unit> ; 
! <compilation unit> ; 


<context> #= 
USE DATA <sequence of: identifiers > ; 


<compilation unit> == 
<data segment» 

! program segment» 
! <data partition» 

! <program partition) 


USE DATA MAIN, A; 
PROGRAM SEGMENT A; 
BEGIN 


END: 


USE DATA MAIN, LEXICALANAL ; 
DATA SEGMENT TABLEMANAGER ; 


END ; 
PROGRAM PARTITION TABLEMANAGER ; 


END; 


A compilation is formed by a context followed by one or several compilation 
units. . 


Data segments and data partitions are groups of declarations. They differ in 
terms of visibility rules (see 6-3. and 6-4.). A program segment is a sub- 
program whose program body is separately compilable. A program partition 
is a group of program bodies which are compiled together. 


The identifiers of the context define the actual visibility. They are the names 
of the data segments, and/or data partitions which must be seen by the 
compilation unit(s) of the compilation considered. 


When data segments and data partitions are compiled, permanent symbol 
tables are produced. These tables are later reused by the compiler when the 
corresponding segment or partition name is used in a context. Thus a seg- 
ment or partition whose name appears in the context of a compilation must 
have been compiled before the latter compilation. This is checked by the 
compiler. In addition, if a given segment or partition, say A, is recompiled, 
the tables produced for the compilation of segments and partitions which 
mention A in their context, become obsolete. The compiler checks that the 
tables associated with the names mentioned in the context are not obsolete. 
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6-3.1. Syntax 


6-3.2. Examples 
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segment acclatatignss= 
«sequence of identifiers» : PEGMENT FCeaborearen type > 


<data segment> «= 
DATA SEGMENT <identifier> ; “declaration list) END 
! DATA SEGMENT <identifier> ; «declaration: list> 
<data implementation part> 


 €program segment > «= 


PROGRAM SEGMENT <identifier> ; declarative part» <block > 
! PROGRAM SEGMENT <identifier> ; <block> 


DATA SEGMENT MAIN ; 
TYPE MESSAGE = ROW CONSTANT (1..100) OF CHARACTER ; 
TYPE DESCRIPTORS. = 
PLEX 


END: 

DICTIONARY : DOMAIN OF DESCRIPTOR ; 

WARN : ACTION (ERROR : MESSAGE) ; 

SYNTAXANAL, LEXICALANAL, SEMANTICS : SEGMENT ACTION : 
IMPLEMENTATION 


END; 


PROGRAM PARTITION MAIN: 
PROGRAM WARN; 
END; 

END: 

USE DATA MAIN ; 

DATA SEGMENT LEXICALANAL ; 


BUFFER : ARRAY (1..80) OF CHARACTER ; 
SCANNER, TABLEMANAGER : SEGMENT ACTION ; 


END: 

USE DATA. MAIN, LEXICALANAL : 
PROGRAM SEGMENT LEXICALANAL : 
CHECKLEXICALTYPE : ACTION ; 

PROGRAM CHECKLEXICALTYPE : 


END ; 
BEGIN 


END; 


622.3. Visibility in a segment hierarchy 


Visibility and general program structure 


In the usual case, a separately compiled subprogram will give rise to two 
compilation units. Let B be that ‘subprogram, its name appears : 


(a) ‘In the declaration.of the segment B: 
B: SEGMENT ACTION .. 


(b) In the data segment of B : 


. DATA SEGMENT B;... END; 
(c) In the program segment of B : 
_ PROGRAM SEGMENT B ;... END ; 


The declaration of each segment must appear in some data segment. The 
only exception is for the main program (in the usua} meaning). It is assumed 


- to be implicitly declared with the name MAIN. 


The hierarchy of segments cannot rely on textual nesting since segments are 
separately compiled. This hierarchy then relies on the atouoMing definition of 
the relation /nner to for segments : 


_{1) A program segment is said to’ be inner to the data segment having the 


6-3.3.1. Notes 


same name. 


(2) If B is a segment declared in a data segment A, the data segment B is 
_ said to be inner to the data segment A. 


With this definition, the visibility rule defined in 6-1.3. may be extended to 
segments. An identifier declared in a given data segment is visible in all 
segments which are inner to the segment considered. A program segment 
may be considered as a program body, and the usual visibility rules apply for 
identifiers declared in a program segment. 


(a) The names declared in all segment declarations and in all partition 
declarations must be distinct. 


(b) For a subprogram which is a leaf of the segment hierarchy there is no 
necessity to create both a data segment and a program segment, the 
latter is enough. 


(c) The program bodies of actions declared in a data segment (including 
those of plex and schema attribute subprograms which are not 
segments) must be placed in a program partition bearing the same 
name as the data segment (see 6-4.3.). This program partition is con- 
sidered as inner to the associated data segment. 
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6-3.3.2. Annotated example 
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Assuming that A is declared as a segment in MA/N, example 6-1.3.1. may 
be rewritten as a sequence of 10 compilations : 


USE DATA MAIN ; 
DATA SEGMENT A; 
IJ: INTEGER ; 


B,C : SEGMENT ACTION ; 


END; 


USE DATA MAIN, A; 
DATA SEGMENT B ; 
K : INTEGER ; 


D,E: SEGMENT ACTION ; 


END: 


USE DATA MAIN,A,B; 
DATA SEGMENT D; 

M : INTEGER ; 
END; 


USE DATA MAIN, A,B ; 
DATA SEGMENTE; 

N : INTEGER ; 
END; 


USE DATA MAIN, A; 
DATA SEGMENT C; 
L: INTEGER ; 

END; 


USE DATA MAIN, A: 


PROGRAM SEGMENT A ; 


BEGIN 
block of A 
END; 


USE DATA MAIN.A.B ; 


PROGRAM SEGMENT B ; 


BEGIN 
block of B 
END; 


USE DATA MAIN, A, ve 

PROGRAM SEGMENT D ; 

BEGIN pe 
block of Bo 

END 


USE DATA MAIN, A.B,E ; 
~ PROGRAM SEGMENT E ; 
BEGIN 


block of E 
END; 


USE DATA MAIN, A,C : 
PROGRAM SEGMENT C: 
BEGIN 

block of C 
END ; 


The segment hierarchy is shown in the following diagram ; the arrows cor- 
respond to the relation /nner to. Thus, it appears that the identifiers declared 
in the data segment D, B and A are visible in the program segment D : 


PROGRAM C 


PROGRAM E 
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6-4. Partitions = 


6-4.1. Syntax 


6-4.2. Examples 


<partition declaration «= 
<sequence of identifiers) : PARTITION 
! <sequence of identifiers> : TYPE PARTITION 
! sequence of menenets? : EXTERNAL PARTITION 


<data partition> == 
DATA PARTITION Cidentifier) : <declaration list) END 
! DATA PARTITION <identifier> ; <declaration list> 
<data implementation part> 


<program partition «= 
PROGRAM PARTITION <identifier> ; <declarative part> END 
! PROGRAM PARTITION <identifier> ; <program implementation part» 
! PROGRAM PARTITION <identifier> ; <declarative part» 
<program implementation part») 


USE DATA MAIN ; 

DATA SEGMENT SEMANTICS ; 
GENCODE:PARTITION: | 
TREATPARAMETERS : PARTITION ; 

END: 


USE DATA MAIN,SEMANTICS :; 

DATA PARTITION TREATPARAMETERS ; 
SIMPLEPARAMETER,FORMALPARAMETER : ACTION ; 

END ; 


USE DATA MAIN,SEMANTICS ; 

DATA PARTITION GENCODE ; 
GENADD,GENMULT,GENDIV,GENSUB : ACTION ; 
TYPE INSTRUCTION = 

PLEX 


END: 
END: 
USE DATA MAIN,SEMANTICS,GENCODE ; 
PROGRAM PARTITION GENCODE : 

BUFCODE : ARRAY (1.. 100) OF INSTRUCTION ; 

PROGRAM GENADD: 

BEGIN 


END: 
PROGRAM GENSUB:; 
BEGIN 
END ; 


END ; 


_USE DATA MAIN, SEMANTICS, GENCODE, TREATPARAMETERS ; 


PROGRAM SEGMENT SEMANTICS ; 
BEGIN 


SIMPLEPARAMETER ; 
GENADD ; 


END: 


59 


The system implementation language WISE 


6-4.3. Semantics 


If a data segment is considered too large, it may become desirable to split it 
into smaller compilation units. However changes in the segment hierarchy 
may be undesirable. Similarly, if the declarative part of a program segment 
contains several small. subprograms, it may be desirable to split that 
program segment. However, creating a separately compiled segment for 
each subprogram may be inconvenient. - 


Data partitions and program partitions provide an answer for these two 
situations. Several declarations may be grouped into a data partition to form 
a compilation unit. Similarly a program partition contains a declarative part 
(i.e. declarations and program bodies) and forms a compilation unit. Another 


.. motivation for the partition concept is to permit a refinement of the visibility 


rules (see 6-4.3.1.). 


A partition name, say P, may appear in: 


(a) A partition declaration : 
P : PARTITION: 


This declaration can only appear in a data segment. The space 
necessary for the partition data and the partition program (if any) is 
reserved as a result of the execution of the partition declaration, and the 
initializations (if any) are executed. 


(b) The definition of the data partition : 
DATA PARTITION P;...END; 

(c) The definition of the program partition : 
PROGRAM PARTITION P;... END; 


If a data partition contains only type and data declarations, no program 
partition is associated with it. On the other hand, if it contains subprogram 
declarations, their program bodies must be in a program partition bearing 
the same name as the data partition (see also 6-3.3.1., note (c)). 


6-4.3.1. Potential visibility and actual visibility 
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In a segment hierarchy including data partitions two forms of visibility must 
be considered : the potential visibility and the actual visibility. 


The potential visibility is defined by extension of the rules given for 
segments. Any identifier declared in a data partition is potentially visible at 
any program point where the partition declaration is visible. In addition, a 
program partition is considered inner to the data partition (or segment) with 
the same name. 


The actual visibility for a given compilation is specified by the sequence of 
segment and partition names which appear in the context. These names 
must be part of the potential visibility. As a consequence the set of iden- 
tifiers which correspond to the actual visibility is always a subset of the 
identifiers potentially visible. 


Notes: 


(a) In order to avoid circular situations, a partition P declared textually 
before a partition Q, and in the same data segment as Q, does not see Q 
potentially. 


. (b) The unique visibility restriction is applied in terms of actual visibility. 


6-4.3.2. Annotated example 


6-4.3.3. Type partition 


6-4.3.4. External partition 


Visibility and general program structure 


It is assumed thatA isa pegiven: declared in MAIN. 


USE DATA MAIN : 
DATA SEGMENT A; 


USE DATA MAIN ; 


_ DATA PARTITION P ; 


B,C: SEGMENT ACTION ; P1:ACTION: 
P.Q:PARTITION: © P2 : ACTION ; 
END; | END; 
USE DATA MAINA; USE DATA MAIN,B : 
DATA SEGMENT B;; DATA PARTITION R ; 
R,S: PARTITION ; Rt: ACTION: 
ne | R2: ACTION; 
END; ~ R3:ACTION; 
END: 
USE DATA A,B,P,S ; : 


PROGRAM SEGMENT B; 


END; 
In this example the potential visibility within the program segment B in- 
cludes all identifiers declared within the data segments MA/N, A,B and the 


_ data partitions P,0,R,S. Thus the action names P7,P2,R1,R2,R3 are poten- 


tially visible. 


The actual visibility is more restrictive. It includes the identifiers declared 
within the data segments MA/N, A,B and the data partitions P and S. Thus 
whereas the subprograms P7,P2 are visible and may be called from within 
the body of the program segment 8, the subprograms A7,R2,R3 are not ac- 
tually visible and cannot be called. 


A partition declared as TYPE PARTITION may only contain declarations of 
types and of static constants. . 

No object code is produced for type partitions. 

A partition declared as EXTERNAL PARTITION is used to represent external 
data, i.e. data declared in other programs. 


An external partition may not contain subprogram declarations. As a con- 
sequence, a data partition must exist for the external partition but no 
program partition. 


6-5. Impact of changes on recompilations 


One of the advantages of the subdivision of a program text into a sequence 
of compilation units is to avoid the recompilation of the whole text for each 
program change. 


The impact of a change (i.e., which compilation units must be recompiled as 
a consequence of that change) can be inferred from the segment hierarchy. 
The units which must be recompiled are those from which the ehangs) is (ac- 
tually) visible. 


_The following. cases should be considered : 


(a) A change made in a program segment necessitates only the recompila- 
tion of that program segment. . 


(b) A change.made in a data segment necessitates the recompilation of that 


segment and of all the segments and partitions inner to it. 


(c) A change of a program partition necessitates only the recompilation of 
this program partition. 


(d) A change of a data partition necessitates the recompilation of all 
segments and partitions for which the data partition is actually visible, 
namely, those which mention its name in their context. 
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7. Implementation parts 


The description of a LIS program separates the definition of data and 
algorithms from the definition of data implementation. The latter mainly 
covers the description of the elementary management of data, and also of 
its physical organization. One of the advantages of this separation is that 
algorithms which are formulated only in terms of the semantic properties of 
data will remain invariant when data implementation is modified. 


Two language levels exist in LIS, one level used for data declarations and 
algorithms, and the other for implementations. 


Data declarations and algorithms are written in the high-level janguage 
which has been presented in chapters 2 to 6 of this manual. it is a 
declarative language in which every entity has static properties defined by 
its type. These properties are known at compile-time and are kept invariant 
during the execution of a program. As a consequence, a relatively high level 
of programming safety can be reached at that level of the language. Impor- 
tant classes of errors may be detected at compile-time, and other classes of 
errors may often be detected at run-time by means of optional compiler 
generated run-time checks. 


Implementation definitions are written in a language which is the union of 
this high level language and of lower level features. The latter will be useful 
for the treatment of several implementation problems where the type con- 
straints of high level languages turn out to be too restrictive. Thus the defini- 
tion of a memory manager will often be expressed in terms of addresses and 
arrays of words rather than in terms of elements of known type. To this 
relatively low level of language corresponds necessarily a lower level of 
programming safety. Errors made in these parts are often neither detectable 
at compile-time nor at run-time. : 


It follows that this separation of data and algorithms from implementation 
definitions will induce a clear textual separation into program parts which 
are safe, and into program parts which are more error-prone. 


Implementation parts are divided into data implementation parts containing 
implementation specifications, and into program implementation parts 
which contain the bodies of the actions declared within the associated data 
implementation part. 


Data implementation parts also include the definition of the means of com- 
municating with programs written in other languages or using special 
linkage conventions. These means of communication, called interfaces, are 


also expressed in terms of lower level language features. 


a e 
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7-1. Data and program implementation parts 


| (7-1.1. Syntax 


<data implementation part) == 
IMPLEMENTATION <declaration list) END 


<program implementation part> no 


IMPLEMENTATION <Cdeclarative part>) END 


<implementation specification> «= 


7-1.2. Examples 


<symbolic type implementation> 
<length specification) 

<array or row implementation> 
<plex type implementation» 
<domain implementation> 
<program implementation» 
<implementation schema» 
<interface model» 


DATA SEGMENT A; 


D,E: DOMAIN OF PERSON ; 


IMPLEMENTATION 


INITIALIZE, REDISTRIBUTE : ACTION ; 


STORAGE : ARRAY (0.. 1023) OF WORD; 


. SCHEMA S; 


BOTTOM :REF; 
REORGANIZE : ACTION ; 
END ; 
SCHEMA T; 


END: 
FOR D USES: 
FOR E USET: 


END ; = 
PROGRAM PARTITION A: 
IMPLEMENTATION 


PROGRAM INITIALIZE ; 
BEGIN oct 
S . BASE := STORAGE @ WORDADDRESS ; 
END ; 
END ; 


7-1.3. Semantics 


PROGRAM S.ALLOCATE ; 
BEGIN : 
REDISTRIBUTE ; 


END; 
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A data implementation. part may follow the declaration list ‘of a data 


segment (or partition). It contains implementation specifications and 
possibly other declarations. Implementation specifications serve mainly to 
‘specify the physical data layout in core which is to be used for elernents 
declared in the segment (or partition). An implementation specification 
associated with a type declaration applies to all elements which are of this 
type. ; . 
Elements and types declared in the segment (or partition), but for which no 


implementation specification is given, are implemented in a standard 
manner by the compiler. — 
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7-2. Special features 


7-2.1. Syntax 


7-2.2. Examples 


7-2.3. Semantics 


7-2.3.1. Length units 


7-2.3.2. Qualified denotations 


Implementation parts 


The subprograms declared within a data implementation part are visible in 
the same conditions as identifiers declared in the associated segment (or 
partition). On the other hand, the other identifiers of the data implementa- 
tion part are only visible from data and program implementation parts of 
segments or partitions which are inner to the data segment (or partition) 
considered. 


A program iaplementaten part may follow the declarative part of a program 
partition. It contains the bodies of the subprograms declared within a data © 
implementation part. In particular, it may contain the program bodies of the 
schema attributes ALLOCATE and FREE. It may also contain other 
declarations. 


<type> = 
<length unit> 


<length unit> s= 
-BIT 


! BYTE 

! HALF 

! WORD 

! DOUBLE 


<variable denotation> == 
< qualified denotationd 


<qualified denotation> «= 
(<simple expression> AS <type name» ) 


nature» s= 
VULNERAB ce. 


<indirect name> «= 
<schema attribute > 
! <domain attribute» 


STORAGE : ARRAY (0..1023) OF WORD ; 
BOTTOM,CURSOR : INTEGER ; . 
(CURSOR AS PERSON ). FATHER; 
(BOTTOM AS DATE). YEAR: 

X:=('A’ AS INTEGER); 

C :=(64 AS CHARACTER ) ;. 


The language features and standard attributes described in this section can 
only be used : 


(a) in an implementation part, 
(b) in the parameter assignments of a subprogram declared in an im- 
plementation part. 


_ Note that in the latter case this use is permitted even if the call of the sub- 


program considered is not in an implementation part. 


Schema and domain attributes are explained in section 7-7. They may be 
used as indirect names. ; 


Length units such as B/T, BYTE, HALF, WORD and DOUBLE may be used as 
types, mainly in arrays and plexes. Their lengths in nS is machine 
dependent. 


The value of an expression which appears in a qualified denotation is 
interpreted as a value of the type mentioned after the keyword AS. Thus in 
the examples of 7-2.2, X is assigned the EBCDIC code of the character A, 
and C is assigned the character which has the EBCDIC code 64. | 
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7-2.3.3. Arithmetic on references 


7-2.3.4. Standard attributes 


7-2.3.5. Vulnerable variables 


In the high-level part of the LIS language no arithmetic may be performed 
on reference variables. 


This restriction is relaxed in implementation parts : computations may be 
performed on references by means of expressions containing qualified 
denotations. Thus given the declarations : 


TYPE T=REF D; 
X:T: 
1 :- INTEGER; 


- The following statements are legal in an implementation part : 


(XAS INTEGER) :=1+1; | 
X:=(((X AS INTEGER) +1) AS T); 


The following standard attributes may be used to denote properties which 
result either from the declaration or from the implementation of the cor- 
responding entites. 


(a) WORDSIZE, BYTEZIZE, BITSIZE are standard attributes of variable 
denotations, type names and program names. They-denote the size of a 
variable, the size of objects of a given type and the size of the space 
needed on the.stack for an activation of a procedure (dynamic arrays ex- 
cluded). This size is an integer expressed in words, bytes or bits, depen- 
ding on the attribute. 


(b) WORDADDRESS, BYTEADDRESS are standard attributes of variable 
denotations and program names. They serve to denote the address of a 
variable or the address of the code of a subprogram. This address is an 
integer expressed in words or in bytes, depending on the attribute. 


Examples : 


CHARACTER @ BITSIZE 

DATE. YEAR @ BITSIZE 

DATE @ BYTESIZE 

INPUTUNIT @ BYTEADDRESS 
RECOVERABNIO @ WORDADDRESS 


Notes: 


For a row or.a dynamic array, WORDADDRESS and BYTEADDRESS 
designate the address of the array descriptor. On the other hand, the ad- 
dress of the zeroth element of the array is denoted by the array attribute 
BASE (see 3-4.5.). 


For a plex with variable parts, the size given is the maximum size. 
Variable declared with the nature VULNERABLE are signaled to the 
compiler as being variables for which no optimization should be attempted. 


Global variables modified by subprograms, which are called following in- 
terrupts, should be declared vulnerable. 


7-3. Symbolic type implementations 


| 7-3.1. Syntax 


7-3.2. Examples | 


-7-3.3. Semantics 


ZL 


<symbolic type implementation» n= 
FOR <type name> USE <aggregate primary> 


FOR OPCODE USE 


(<CW> == #31, <AW> == #30, <STW> == #35, <LW> == #32, 
<SW> == #38, <MW> == #37, <DW> == #36): 
FOR ADDRESSMODE USE ( < DIRECT> == 0, <INDIRECT> == 1); 


A symbolic type implementation is used to assign specific values to the 
internal codes of the symbols of a symbolic type. It is expressed in the form 
of an array aggregate primary whose index nature is the symbolic type con- 
sidered and whose elements are integer values. 


7-4. Length specifications 


7-4.1. Syntax 


7-4.2. Examples 


7-4.3. Semantics 


_/mplementation parts 


<length specification) «= 
FOR <type name> USE Achat unit> <dimension> 
! FOR <type name> USE BASED <length unit> <dimension> 


FOR COLOR USE BYTE 1; 
FOR DEVICE USE BASED HALF 1: 


The first form of length specification may be used for discrete, set, index, 
and reference types in order to specify the length of variables and attributes 
of the type considered. 


In general, this length should be greater than or equal to the minimum 
length which results from the type declaration. The only possible exception 
is for reference types. 


_ The second form of length specification may only be used for index and 
_ reference types : 


(a) For an index type, it specifies that indexes of this type should be im- 
plemented as offsets relative to the BASE attribute of the array. This im- 
plies that the conversion from an integer to an offset is performed when 
the integer is assigned to the index (and not when the index is used to 
access an array element). 


(b) For a reference type it specifies that references of this type should not 
be implemented as addresses but rather as offsets relative to the BASE 
attribute of the schema used for the domain. 


In both cases the length specified indicates the size of the fields containing 
these offsets. 


7-5. Array and row implementations 


7-5.1. Syntax — 
7-5.2. Examples 


7-5.3. Semantics 


<array or row implementation> t= 
FOR <type name> USE PACKING 


TYPE BITVECTOR = ARRAY (0.. 31 ) OF BOOLEAN ; 
FOR BITVECTOR USE PACKING ; 


The type name used in this specification must be that of an array or row type 
and their elements must belong to a discrete or set type. 


The specification indicates that elements of such arrays or rows must be 
packed. Thus for a packed array of booleans, each element occupies one bit 


and the bits used for two consecutive elements are contiguous. 


lf no packing is specified for an array, its elements are implemented on the 
smallest addressable unit (e.g. one byte per boolean element). 


Restrictions : 


A packed row may only designate a packed array. Conversely a packed array 
may only be designated by a packed row. 


For slice comparisons and assignments, the terms of the operation must 
either be both packed or both not packed. 
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7-6. Plex type implementations 


7-6.1. Syntax 


7-6.2. Examples 
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<plex type implementation #= 
FOR <type name> USE <plex implementation > 


<plex implementation «= 
PLEX <attribute implementation list> END 
! PARALLEL <attribute implementation list) END 


<attribute implementation list) == 
<attribute implementation list> <attribute specification ; 
! <attribute specification) ; 


attribute specification> «= 


<attribute» : <attribute support> <offset> : 
! attribute> : (attribute support> 
| <alignment specification > 
! <parallel support> 


<attribute support> == 
_ <length unit> ( Corigin> : <dimension> ) 
! <length unit> <dimension > 


<offset> = 
OF WORD <simple expression > 


<alignment specification == 
USE <length unit> 


< parallel support> #= 
<identifier> : length unit> <plex implementation > 


FOR INSTRUC USE 

PLEX 
ADDRESSING : BIT (0:1) OF WORD O; 
OPERATION : BIT (1:7): 
OPERAND : BIT (8:4); 
INDEX: BIT (12:3); - 
ADDRESS : BIT (15:17); | 

END ; 


FOR DATE USE 
PARALLEL 
MONTH : BYTE 1; 
DAYYEAR : HALF 
PLEX 
DAY:BIT 5; | 
YEAR : BIT 11; 
END; 
END; 


FOR DATE USE 
PLEX 
USE WORD ; 
MONTH: BYTE 1; ~ 
DAY: BYTE 1; — 
YEAR : BYTE 2; 
END ; 


7-6.3. Semantics 


7-6.3.1. Attribute supports 


7-6.3.2. Serial implementations 


Implementation parts 


A plex type implementation specifies the supports to be used for the 
attributes of plexes of that type. In addition, it specifies whether the im- 
plementation should be serial or parallel for plexes which appear in an array 
or in a domain. 


In the absence of an implementation specification for a given plex type, a 
- serial implementation is adopted and the supports are defined in a standard 
_ way by the compiler. 


The support of an attribute is the field which is reserved in memory for the 
attribute. The size of this field must be greater than or equal to the minimum 
size needed to store the attribute. Thus the minimum size needed to store a 
boolean attribute is one bit. However, one byte may be reserved to a 
boolean attribute in order to decrease access time to the attribute. This byte 
is said to be the support of the boolean attribute. ‘ 


The definition of an attribute support may contain an origin and a dimension 
which must be static integer constants. They are assumed to be expressed 
in the length unit mentioned in the attribute support. 


In a serial implementation, the attributes of a plex generally have supports 
which are consecutive in memory. Each support is located by : 


(1) the offset in words of the word containing the start of the support, 

52) its origin, i.e., the displacement of the start of the support within this 
word, 

53) its dimension (or width). 


A plex type implementation may be more or less complete : 


(a) Some attributes may be left unspecified ; they are implemented in a 
standard manner by the compiler. 


(b) If an alignment specification is given, it must appear as the first attribute 
specification of the plex implementation. By default, a word alignment is — 
used. 


(c) For an attribute support mentioning a dimension but no origin, the com- 
piler is left free to assign an origin compatible with possible alignment 
constraints resulting from this dimension. 


(d) For an attribute specification mentioning both an origin and a dimen- 
sion, but no offset, the compiler is left free to assign the actual offset of 
the attribute. 


(e) Plex implementations using offsets must be complete ; an offset must 
be given for the first attribute specification, and specifications for all at- 
tributes of the plex type must be present. Attribute supports with no ex- 
plicit offset implicitly use the last offset indicated in a previous attribute 
specification. 


Example : 


FOR P USE 
PLEX 
USE WORD ; 
A:WORD 1 OF WORD 0; 
B:HALF(O:1)OF WORD 1 ; 
C:HALF(1:1); 
END ; 


69 


The system implementation language LIS 


7-6.3.3. Parallel implementations 


The implementation of plexes in arrays or domains may be parallel. In this 
mode the plex attributes are distributed in parallel arrays. A given plex is 
then located by an ordinal which is also the position of each attribute in its 
array. 


The only forms of attribute specifications available in parallel implemen- 
tations are: 


(a) <attribute> : <length unit> <dimension> 
This form indicates that attributes of the name mentioned are grouped 
in an array and that each of them occupies the length specified. - 


(b) <parallel support> 


A parallel support groups in a common array several attributes im- 
plemented serially. 


Example 17: 


FOR P USE 
PARALLEL 
A:WORD 1; 
B:HALF 1; 
_C:HALF 1; 
END ; 


Example 2 (with parallel support BC) : 


FOR P USE 
PARALLEL 
A:WORD 1; 
BC : WORD 
PLEX 
B:HALF 1; 
C:HALF 1: 
END; 


END ; 


lf 7 is an array of plexes P implemented in parallel, the bases of the parallel 
arrays are array attributes. Thus for example 2, they are denoted 7.A and 
T.BC. 


| 7-6.3.4. Standard attributes of plexes and attributes 
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The information given in plex implementations (or the equivalent 
information established by default by the compiler) may be accessed by the 
standard attributes AL/GNMENT, LENGTHUNIT, DIMENSION, ORIGIN and 
OFFSET in implementation parts. For the following explanation, P stands for 
the name of a plex type and A for one of its attributes : 


(a) P@ ALIGNMENT gesgnetes the length unit used for the alignment. It is 
expressed in bits. 


(b) P.A @ LENGTHUNIT designates the length unit used for the attribute 
A. It is expressed in bits. - 


(c) P.A @ DIMENSION and P.A @ ORIGIN designate the dimension and 
the origin of the attribute A. They are expressed in the length unit used 
for A. 


(d) P.A @ OFFSET designates the offset of the attribute A. It is expressed 
in words. 


Example (for the plex P of 7-6.3.2.) ‘ 


P @ALIGNMENT = 32, P.A @ LENGTHUNIT = 32, 
P.A @ DIMENSION = 1, P.A @ ORIGIN = 0, P.A @ OFFSET = O. 


7-7. Implementation schemas and domain implementations 


7-7.1. Syntax 


7-7.2. Example 


<implementation schema) == 
SCHEMA <identifier> ; <declaration list) END 


<domain implementation > «= 
FOR <domain name> USE <schema name> 


<schema attribute» == 
<schema name>. <attribute > 
1! <schema name>. ALLOCATE 
| <schema name>. FREE 


<domain attribute» == 
<domain name> . attribute» 


D : DOMAIN OF PERSON ; 


SCHEMA NORMAL ; 
BOTTOM,CURSOR,FIRSTFREE : INTEGER ; 
EMPTY : BOOLEAN ; 

INITIALIZE : ACTION ; 


END: 
FOR D USE NORMAL; 
TYPE CELL = 
PLEX 
NEXT : INTEGER ; 
END; 


TYPE LINK = REF CELL; 


PROGRAM NORMAL. ALLOCATE ; 
BEGIN 
IF EMPTY THEN 
POINTERVALUE := CURSOR ; 
CURSOR := CURSOR + LONGELEM ; 
IF CURSOR > BOTTOM THEN 
EMPTY := FALSE; 
. END; 
END ; 
IF NOT EMPTY THEN 
IF FIRSTFREE = NIL THEN 
ERROR: 
ELSE 
POINTERVALUE := FIRSTFREE ; 
FIRSTFREE :=(FIRSTFREE AS LINK) .NEXT ; 
END; 
END : 
END: 


PROGRAM NORMAL. FREE; 

BEGIN 
( POINTERVALUE AS LINK). NEXT := FIRSTFREE ; 
FIRSTFREE :=POINTERVALUE ; 

END; 


PROGRAM NORMAL. INITIALIZE : 
BEGIN 
BASE :=...;: 
CURSOR := BASE: 
BOTTOM := BASE +...: 
EMPTY := TRUE; 
FIRSTFREE := NIL; 
END; 


Implementation parts 
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7-7.3. Semantics 2% x ... . ..The purpose of a domain implementation is to specify which actions should 
be called for the execution of ALLOCATE and FREE statements for plexes of 
the domain considered. This is achieved by specifying the implementation 
schema which should be used for this domain. 


An implementation schema contains the declarations of data items and ac- 
tions called schema attributes: |n addition the following attributes are 
predeclared in every schema : 


ALLOCATE : ACTION ( POINTERVALUE : OUT INTEGER ) ; 
FREE :ACTION ( POINTERVALUE : IN. INTEGER ) ; 

~ LONGELEM : INTEGER; | 
BASE : INTEGER ; 


Schema attributes‘may be named directly in the program bodies of action 
attributes ‘of the schema. The indirect notation <schema name>. <at- 
tribute> may be used elsewhere in implementation parts. 


The attribute BASE must be’set equal to the address of the memeory*area 
used for plex allocation. : 


Before each call of an ALLOCATE action, the compiler generates instruc- 
tions computing the length of the plex to be allocated and storing that 
length into the schema attribute LOVGELEM. 


Domain attributes are only defined for domains of plexes implemented in 
parallel. Each domain attribute corresponds to one of the parallel arrays 
used for the domain implementation and serves as a base for this array. 
Thus, for a domain D of plexes of type P (see 7-6.3.3., example 2) the bases 
will be denoted by the domaine attributes D.A and D.BC. 


An implementation schema may serve to implement several different 
domains. In such case, the same action ALLOCATE and the same action 
FREE are used for the domains considered. 


A domain implementation may only appear in the implementation part of 
the segment (or partition) containing the domain declaration. By default a 
_ standard schema may be used by the compiler. 


‘Note : aa 


BASE and LONGELEM are Oreo in the adressing unit of the machine 
considered. 


7-8. Interface models and program implementations 


7-8.1. Syntax _<interface model» == 
. | «INTERFACE: identifier) : <register convention list) END 
! INTERFACE <identifier> ; <register convention list> <block> 
! INTERFACE <identifier> ; <block> 


<register convention list> «= 
<register convention list > <register convention > ; 
! <register convention > : 


<register - convention) == 
<identifier> : <mode> Cieaisters 
! RETURN: <register> 
|! USE <sequence of registers > 


<sequence of registers) == 
<sequence of registers» ; Cregister) 
! <register> 
<statement> «= ' 
<inline statement> — 
<program implementation» «= 
FOR <program name> USE <interface name> 
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7-8.2. Example 


7-8.3. Semantics 


Implementation parts 


P : INTEGER ACTION (X:ININTEGER ;Y:ININTEGER); | 
INTERFACE LINK ; 


X : IN RS: 

Y : IN R4; 

RETURN : RO; 

USE Ri, R2, R14; 
BEGIN 

BAL, R14 LINK; 
END; 


FOR P USE LINK; 
INTERFACE SIMPLE ; 


Lo: IN R5; 
M : OUT R6: 
END: 


Interface models are used to define the linkage conventions with programs 
written in other languages or with LIS programs called in a non standard 
mode. . 


The register conventions of an interface model specify : 


(a) <identifier> <mode> <register> 


the name and mode of identifiers (called the interface parameters) and 
the mode of parameter assignment (/N, OUT or /N OUT), 


(b) RETURN: <register> 


the register in which the result of the action should be returned (if a 
function), 


(c) USE <sequence of registers» 
the registers modified by the called program. 


An interface model may also contain a block. The list of statements of this 
block must be a list of inline statements. These correspond to instructions of 
the machine considered. 


A program implementation specifies the interface model which must be 
used for a given subprogram. This specification is only correct if the names 
and modes of the subprogram parameters are identical to the names and 
modes of the interface parameters. 


If the subprogram implemented is written in LIS, the register conventions of 
the interface model will be obeyed by the compiler for the compilation of the 
subprogram. 


If the interface model includes a block, its instructions are inserted in line in 
place of each call of a subprogram using this interface. Prior to this insertion, 
the name of the subprogram is substituted for the name of the interface 
model in inline statements where it appears. 


Note: 


The syntax of inline statements and the designation of the registers are 
machine dependent. They must be specified separately for each L/S com- 


piler. 
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7-9. Dynamic coherence . 


7-9.1. Syntax 


7-9.2. Example 


7-9.3. Semantics 


74 


<membership relation == 
<primary> COHERENT AS <type name> 


TYPE: P= 
PLEX 
A: BOOLEAN ; 
B : COLOR ; 
END; 
xX REF P; 
IF(X.B COHERENT AS COLOR)AND 
(X.A COHERENT AS BOOLEAN)THEN ... 


Membership relations may be used to check dynamically the type coherence 
of data read from files or of data in memory areas which may be partially 
erased. 


It was stated in 7-6.3.1. that each attribute has a support whose size is 
greater than or equal to a minimum size which depends on the type of the 
attribute. As a consequence, bit configurations for values of that type are 
often only a subset of the possible bit configurations for values of the sup- 
port. Practically this fact may be used to check dynamically if the value of a 
primary is coherent (plausible) given some type hypothesis. 


Thus for the example 7-9.2. if we assume the implementation 


FOR P USE 
PLEX 
A:BYTE1; 
. B:BYTE1; 
END: 


and if a byte contains 8 bits for the machine considered, then the values of 
the support of A are in the range ( 0..255 ). However, only values of this sup- 
port which correspond to the internal values of 7RUF and FALSE are 
coherent with the type BOOLEAN. 


Coherence tests for plex and array types are not permitted. An equivalent 
effect may be programmed as a sequence of coherence tests on attributes 
or on array elements. 
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A. Non standard features | 


The language features presented in this appendix are not part of the 
standard definition of the LIS language. 


A-1. Prefixes 


A-1.1. Syntax’ <declaration> «= 
<prefix specification > 


<prefix specification) «= 
USE PREFIX <type name> 


A-1.2. Example TYPE P= 
PLEX 
A : INTEGER: 
B : ACTION; 
END; 
TYPE-O = 
PLEX 
USE PREFIX P; 
C : INTEGER ; 
END: 
A-1.3. Semantics The name of a plex type may be specified as prefix in a plex type declaration. 


The prefix specification must appear as the first declaration in the plex type 
declaration, and only one prefix is allowed. 


The effect of the prefix specification is to add the attributes of the prefix to 
the prefixed plex type. Thus, in the example A-1.2., the attributes of plexes 
of type Q are A, C and the action B. 


A-1 
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- A-2. Regions = 


A-2.1. Syntax 


A-2.2. Examples 


A-2.3. Semantics 


<type> 3 
<region type > 


<region type> «= | 
REGION <list of attribute definitions> END 
<with statement) «= 
RESERVE <item initialization) DO <statement list> END 


. Region prefix declaration : 


TYPE SHARED = 
PLEX 
SEMAPHORE : ...: 
WAIT, SIGNAL : ACTION: 
END; 
PROGRAM SHARED. WAIT: 
BEGIN 


END; 

PROGRAM SHARED. SIGNAL ; 
BEGIN 

END: 

Region declaration : 


BUFFER : 
REGION 
USE PREFIX SHARED; 
MESSAGESENT : BOOLEAN; 
MESSAGE : ARRAY (1..20) OF CHARACTER : 
END; 


Reserve statement : 


RESERVE B == BUFFER DO 
B.MESSAGE (1..20):='...’; 
B.MESSAGESENT := TRUE ; 


END; 


The execution of asynchronous programs involves accesses to shared 
resources in critical sections. The. mechanisms used for synchronizing these 
accesses are part of the definition of the kernel of an operating system. It is 


- thus out of question to propose a unique treatment of these notions in a 


system implementation language. It is yet of interest to provide a syntactic 
skeleton for these notions as well as mechanisms to define their actual im- 
plementation. Indeed, there are limitations to the optimizations that can be 
made to these program sections. Hence the need to identify them clearly. 


A region represents a group of data items which may be accessed by several 
processes in an asynchronous manner. Its declaration is analogous to a plex 
declaration. In addition, it must specify a prefix, in which the mechanisms for 
mutual exclusions are provided in the form of the attribute actions WA/T and 
SIGNAL. 


The access to the attributes of a region is only possible within a RESERVE 
statement. It is compiled as a W/TH statement containing the same state- 
ment list, and enclosed between a call of the attribute action WA/T and a 
call of the attribute action S/GNAL. 


Non standard features 


A-3. Processes 


A-3.1. Syntax 


A-3.2. Examples 


A-3.3. Semantics 


Thus, the reserve statement of example A-2.2. is equivalent to the following 
statement: 


B.WAIT : 
B.MESSAGEW( Pue20 ts aS 
B.MESSAGESENT := TRUE; 
B.SIGNAL : 

END; 


Note: 


The same region cannot be reserved by two nested reserve statements 
(since a deadlock would result). 


<subprogram nature> = 
PROCESS ACTION 
! PROCESS PROCEDURE 


<reference type > «= 
REF PROCESS 


<qualified denotation > «= 
(<simple expression> AS <program name> ) 


SYMBIONT : PROCESS ACTION ; 
DISKACCESS : PROCESS PROCEDURE ; 
THISACCESS : REF PROCESS ; 
{(THISACCESS AS SYMBIONT) 


Processes represent programs which may be activated asynchronously. A 
process action exists in only one instance. The space needed for its local 
data may be allocated at compile-time. On the other hand, several instances 
of process procedures may be created dynamically. The memory space 
needed for the local data of each instance must be allocated and bound to 
the process code at run-time by primitives of the operating systems kernel. 


Reference variables of type REF PROCESS are used to denote process in- 
stances. A qualified denotation may be used in indirect names to refer to a 
region of a given process instance. 
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B. Index of Special Symbols 
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C. Index of Syntactic Definitions and Uses 


Syntactic symbol | Definition Uses 


| A 
ACTION 3-8 3-8 5-2 A-3 
<adding operator> 4-2 4-2 
<aggregate primary» 4-4 4-2 7-3 
<alignment specification» 7-6 7-6 
ALLOCATE 5-10 5-10 7-7 
<allocate statement» 5-10 5-0 
<alternative > 5-4 5-4 
<alternative list 5-4 5-4 
AND 4-2 4-2 
ARRAY 3-4 3-4 
<array element» 4-1 4-1 
<array or row implementation > 7-5 7-1 
<array or row name> 3-5 3-5 4-1 
<array type» 3-4 3-0 
AS 7-2 7-2 7-9 A-3 
<assignment statement» 5-1 5-0 . 
<attribute > 4-1 3-3 4-1 7-6 
7-7 
<attribute implementation list 7-6 7-6 
<attribute specification > 7-6 7-6 
<attribute support > 7-6 7-6 
B 
BASED 7-4 7-4 
<basic loop» 5-5 5-5 
BEGIN 6-1 6-1 
BIT 7-2 7-2 
<block> 6-1 6-1 63 7-8 
BYTE 7-2 / 7-2 
C 
CASE 3-3 3-3 5-4 
<case statement» 5-4 5-0 
<case statement head» 5-4 5-4 
<character string» 4-4 4-4 
COHERENT 7-9 7-9 
-<compilation> 6-2 6-2 
<compilation unit> 6-2 6-2 
<compound symbolic type> 3-1 3-1 
<connection statement» ' 5-2 5-0 
CONNECTOR 3-9 3-9 
<connector type > - 3-9 3-0 
CONSTANT: 3-0 3-0 3-4 3-5 
3-7 
<context> 6-2 6-2 
3-8 3-8 
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Syntactic symbol _ Definition 


DATA 
<data implementation part» 
< data partition> 
<data segment» 
<declaration> 

- <declaration> » 

- ¢declaration list) 


PPP 
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< declarative part > 


<dimension> 

< discrete integer type > 
<discrete symbolic type > 
<discrete type > 
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DO 

DOMAIN 

<domain attribute» 
<domain implementation> | 
<domain name> 

<domain type > 


‘ i t 


Ges OQ SG GI 
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DOUBLE = 
DOWNTO - 
EACH 5-5 
<element declaration») 3-0 
<element type> 3-4 
ELSE 5-3 
<else part> 5-3 
ELSIF 5-3 
<elsif part> 5-3 
END 3-1 
EXIT 5-6 
< expression > 4-2 
EXTERNAL 6-4 
<factor> << 4-2 
FOR 5-5 
< formal parameter > 5-7 
FREE | a 5-10 

_ <free statement» - - 5-10 
FROM 5-8 

_ function call> 4-2 
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Syntactic symbol - Definition Uses 
H 
HALF iy om a 
I 
<identifier> 3-0 3-0 3-1 5-5 
5-9 6-3 6-4 
7-6 7-7 7-8 
IF 5-3 5-3 5-6 
Cif part 5-3 5-3 
<if statement > 5-3 5-0 
IMPLEMENTATION 7-1 7-1 
<implementation schema > 7-7 7-1 
implementation specification > - 7-1 3-0 
—IN - 3-8 3-8 4-2 5-4 
<index nature > 3-4 3-4 
<index type> 3-5 3-0 
<indirect name> 4-1 4-1 
<indirect name» 7-2 4-1 
initialization > 3-0 3-0 4-4 5-9 
5-10 
<inline statement» 7-8 7-8 
<integer literal> 3-3 3-3 4-2 
INTERFACE 7-8 7-8 
<interface model> 7-8 7-1 
<interface name> — 7-8 7-8 
<interval> 3-1 3-1 3-3 4-1 
4-3 
<item initialization > 4-4 4-4 
<item initialization >’ 5-9 4-4 5-9 A-2 
<iteration condition> 5-5 5-5 
- iteration range» 5-5 5-5 
L 
~ label> 3-3 3-3 
<label part> 3-3 3-3 4-4 5-4 
<length specification > 7-4 7-1 
<length unit> 7-2 7-6 7-4 7-2 
~ LINE 5-11 5-11 
<list of attribute definitions > 3-3 3-3 A-2 
<list of program bodies > 6-1 6-1 
LOOP” / 5-5 5-5 
— <loop exit statement» 5-6 5-0 
<loop label part > 5-5 5-5 
<loop name> 5-6 5-6 
<loop statement> | 5-5 5-0 
M 
<membership relation > 4-2 4-2 
«membership relation > 7-9 4-2 
<mode> * 3-8 3-0 7-8 
MODULO 4-2 4-2 
< multiplying operator > 4-2 4-2 
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Syntactic symbol Definition Uses 


<nature> 
<nature> 


OF 3-2 


- 


<offset> 7-6 
OR 4-2 
<origin > 4-1 

3-8 


OTHERS 
OUT 


t 
DOWANAAN 


WWRAN W 


PACKING 

PAGE 

PARALLEL 

< parallel support) 
<parameter assignment» 
PARTITION 

<partition declaration > 
PLEX . 

<plex implementation > 
<plextype> _ 

<plex type implementation > 
PREFIX : 
< prefix specification > 
<primary> 

PRIVATE 

PROCEDURE 

PROCESS 

PROGRAM 

< program body > 

<program denotation> 
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<program head» 

<program implementation» 
<program implementation part> 
<rogram name> . 
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< program partition) 
< program segment» 
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< qualified denotation> | 7-2 | 7-2 
2 < qualified denotation> A-3 7-2 
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Syntactic symbol Definition Uses 
R 
REF 3-5 3-5 3-7 4-2 
A-3 
<reference type > 3-7 3-0 
<reference type > A-3 3-7 
REGION A-2 A-2 
<region type > A-2 A-2 
<register> 7-8 7-8 
<register convention> 7-8 7-8 
<register convention list > 7-8 7-8 
<relational operator> 4-2 4-2 
REPEAT 5-5 5-5 
RESERVE A-2 A-2 
<result parameter assignment» 5-7 5-7 
RETURN 5-8 5-8 7-8 
<return statement» 5-8 5-0 
ROW 3-4 3-4 4-2 
<row type > 3-4 3-0 
S 
SCHEMA 7-7 7-7 
<schema attribute > 7-7 7-2 
<schema name > 7-7 7-7 
SEGMENT | 6-3 6-3 
<segment declaration > 6-3 3-0 
<sequence of declarations > 6-1 3-8 6-1 
«sequence of expressions > 4-3 4-3 
<sequence of identifiers > 3-0 3-0 6-2 6-3 
6-4 
<sequence of initializations > 4-4 4-4 
<sequence of labels» 3-3 3-3 
<sequence of parameter 
assignments > 5-7 5-7 
<sequence of parameter 
. definitions - 3-8 3-8 
<sequence of program names > 3-9 3-9 
<sequence of registers > 7-8 7-8 
<sequence of symbolic values > 3-1 3-1 
SET : 3-2 3-2 4-3 
<set primary> 4-3 4-2 
<set type» 3-2 3-0 
<simple expression > 4-2 3-1 4-1 4-2 
5-4 5-11 7-6 
7-2 A-3 . 
<simple symbolic type > 3-1 3-1 
<slice> 4-1 4-1 
<standard attribute >. 4-1 4-1 
<standard name > 4-1 4-1 
<statement> 5-0 5-0 
. <statement> 7-8 5-0 
<statement list> 5-0 5-0 5-3 5-4 
5-5 5-9 6-1 
A-2 
<subprogram call> 5-7 4-2 5-0 
<subprogram nature > 3-8 3-8 
<subprogram nature > - A-3 3-8 . 
<subprogram type). 3-8 3-0 6-3. 
<symbol> . 3-3 3-3 4-2 
<symbolic output element> 5-11 5-11 
<symbolic output statement> 5-11 5-0 +=5-11 
<symbolic range> 3-1 3-1 
<symbolic range list> | 3-1 3-1 
<symbolic type implementation») | 7-3 7-1 
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Syntactic symbol | 


<term> 
THEN 


TO 

<true part> 

TYPE 

<type> - 

<type> 

<type> 

<type declaration> 
<type declaration head > 
<type name>» 


<unary operator > 
UNION 

UNTIL 

USE 


VALUE 


<value parameter assignment> 


<value result parameter 


assignment > 


< variable > 
<variable denotation> 


< variable denotation> 
<variable name> 
<variable part> 
<variant> 

<variant list> 
VULNERABLE 


WHILE 

WITH 

<with statement» 
<with statement» 
WORD 3 
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Action 
Actual visibility 
Adding operator 
Aggregate primary 
ALLOCATE statement 
Arithmetic on references 
Array 
attribute 
element 
implementation 
name 
type 
Assignment statement 
Attribute 
Array * 
Constant * 
Private * 
Subprogram 
Subprogram body 
Support 
(See standard attributes) 


Base type of a set type 
BASE. 

of an array 

of a schema 
Bases 

of parallel arrays 

of parallel domains 
Blanks _ 
BOOLEAN | 


CASE statement 
Character 

type 

set 

strings 
Comments 
Compilation unit 
Compilation unit 
Connection statement 
Connector type 
Constant 

attribute 

reference 
Coroutine 

call 


type 


' 
oA 


WO” ww 
bo 


VTREDS 
w 


- 


wo wn 
S 


of ot to bobo’ bor att 


NOMWWWWWUWNYUARW 
—OWWWWARWHHfWOI> 
wo Wo wo & & nw 


a 
: 


ca 
w 


1 | 


NOXDOONNOWWWS 


wo Rw 


N 


| ' ( I ! I ' | 
ero 
dea bad 


WWWWOD®NN NM W 


wa 
o> 


D. Index of Semantic Definitions 


Data implementation part 
Decimal number 
Declaration 
Discrete type 
Domain 

implementation 

name 

type - 
Dynamic array 

in a variable part 
Dynamic coherence 
Dynamic constant 


EXIT statement 
EXTERNAL partition 
Expression 


Fixed array 
FIRST 

of a discrete type 

of an array 
FOR iteration condition 
FREE statement 
Functions (restrictions) 


Hexadecimal numbers 
Hierarchy 
of segments 
program * 
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Identifier 
reserved 
_ IF statement 
Implementation 
part 
schema 
Index type 
Indirect name 
of an array attribute 
of an array value 
of an attribute 
of a plex value 
Inner to 
a program body 
a segment 
INTEGER. 
Integer literal 
Interface 
model 
name 
Iteration 
condition 
range 


Keyword 


Label part 
in a case statement 
LAST 
of a discrete type 
of an array 
Length specification 
Length unit 
Lexical element 
Life-time — 
Local 
Loop 
exit statement 
name 
statement 


Membership relation 
dynamic coherence 
Memory allocation (for data) 
Mode of parameters 
Multiplying operator 
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Name 

NIL 

Notation (syntactic} 
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E. Syntax Summary 


3-0. Declaration 3-2. Set type 
<declaration> == . <set type> s= 
<element declaration> SET OF <discrete type> 


! <type declaration> ! SET OF <type name> 
! <variable part> fed 

! <segment declaration> 
! 
! 
! 


<partition declaration> ee 3-3. Plex type 
<implementation specification > 
NULL <plex type> «= ; 


PLEX <list of attribute definitions> EN 
<element declaration > «= 
<sequence of identifiers> : <nature> <type> <initialization> 
1 sequence of identifiers> : <nature> <type> 
! sequence of identifiers> : <type> <initialization > <variable part> «= 
| <sequence of identifiers> : <type> CASE <attribute> OF <variant list> END 
! CASE <discrete type> OF <variant list> END 
! CASE <type name> OF <variant-list> END 


<list of attribute definitions) #= 
<declaration list> 


<sequence of identifiers> == 
<identifier> , <sequence of identifiers > 


! . identifier) <variant list> x= 
Ghatice sae . | Sate list> <variant> 
CONSTANT ! <variant> 
! PRIVATE <variant> = 
! <mode> <label part> : <list of attribute definitions > 


<type declaration> «= 
TYPE <identifier> = <type> <label part> = 
< “sequence of labels> > 


<type> n= 
<discrete type> <sequence of labels> «= 
*<set type> <sequence of labels> | <label> 
<plex type> ! <label> 
<array type> <label> s= 
<row type> Caymbals 


! 
l 
! 
| 
! <index type> : | <integer literal> 
| <domain type> ! <type name> 

| 

| | i ! 

: | <interval> 

| | 

| 


OTHERS 


“reference type> 
<subprogram type> 
connector type> 
<type name> 


initialization> = 3-4. Array type 


=> <expression> array type> — 
ARRAY <index nature> OF <element type> 


3-1. Discrete type <row type> s= 
: ROW <index nature> OF <element type> 
<discrete type > = ! ROW CONSTANT <index nature> OF <element type> 
<discrete integer type> ; 
! discrete symbolic type> <index nature> s= 


<type name> 


<discrete integer type> == | <discrete type> 


( <interval> ) 
<interval> s= <element type> s= 
ie type 
<simple expression> .. <simple expression > 4 > 


<discrete symbolic type> == 
<simple symbolic type> 
| <compound symbolic type> index type> #= 
REF array or row name> 
{ REF CONSTANT <array or row name> 


3-5. Index type 


<simple symbolic type> == 
( <sequence of symbolic values» ) 


<sequence of symbolic values> #= 


<sequence of symbolic values» | <identifier> , 3-6. Domain type 
! <identifier> Caomainiouese: 
<compound symbolic type> e= DOMAIN OF <plex type> 
UNION <symbolic range list) END ; ! DOMAIN OF <type name> 


<symbolic range list> == 
<symbolic range list> <symbolic range> ; 
! <symbolic range> ; 


* <symbolic range> == 
TYPE <identifier> = (discrete symbolic type> 
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3-7. Reference types. 4-2. Expression 
reference type> n= <expression> == 
REF <domain name> <simple expression> relational operator» <simple sala 
! REF <type name> | <simple expression> 
1 REF CONSTANT <domain name> | <membership relation> 


! REF CONSTANT <type name> aise emiexons = 


<simple cxoreson® <adding operator) San 


3-8. Subprogram type : _<term> 
<subprogram type = <term> s= 
<subprogram nature ( <sequence of parameter definitions» ) Garay <multiplying operator» <factor> 
! <subprogram nature> ! <factor> 
<subprogram nature> == —_ <factor> «= . 
<type name> ACTION <unary operator> <primary> 
! <type name> PROCEDURE | <primary> 
! ACTION _ | REF <primary> 
! PROCEDURE “1 ROW. <primary> 
! COROUTINE Conma= | 
<sequence of parameter definitions> == <variable denotation> 
<sequence of declarations> 1 <symbol> 
, | <integer literal> 
Kmede = 1 NIL 
IN 1. <set primary> 
i SOUT “I aggregate primary > 
| IN OUT function call> 
I. (<expression> } 
3-9. Connector type '. <function call> s= 


subprogram call 
<connector type> #= ak » 


CONNECTOR ( sequence of program names») <membership relation> == 
<simple expression> IN <type name> 


<sequence of program names > == ‘| simple expression> IN <simple expression> 


<sequence of program names> | <program name> 


| <program name> . <relational operator> == 
4-1. Variable and program denotations 1 /= 
: | 
<variable> s= _ 
<variable name> oe 
! array or row name> 22 


<variable denotation> s= 
<variable> 
! <indirect name> a 
! <array element> . Oe 
1 <slice> . war 


<adding operator> == 
+ 


<indirect name> == 


<primary) + Cattribute> <multiplying operator> == 


| <type name> - <attribute> ; ; 
f i . 
! <standard attribute> | MODULO 
<attribute > n= : z ! AND 
< variable» a 
{ <program name> Ssaeal! Seperate 
! VALUE ese 
<array element) #= ! NOT 
<variable denotation> ( <expression> ) 
<slice> s= 4-3. Set primary 
<variable denotation> ( <interval> ) ; 
| <variable denotation> ( <type name> ) <set primary > == 
| <variable denotation> ( <origin> : <dimension> ) SET ( <type name> ) 
| <variable denotation> ( <origin> : « ) ! SET ( <interval> ) 
’ ! SET (<sequence of expressions> } 
<origin> #= 
simple expression) <sequence of expressions> == 
<sequence of expressions» | <expression > 
<dimension> «= ! <expression> 


<simple expression> 


<standard attribute> == 
<variable denotation> @ <standard name> 
| program denotation> @ <standard name> 
1 <type name> @ <standard name> 


<program denotation> == 
_ program name> 
1 <indirect name> 


Syntax Summary 


4-4. Aggregate primary 


aggregate primary> «= 
( <sequence of intializations> ) 
! character string> 


<sequence of initializations> «= 
<sequence of initializations> , <item initialization> 
1 <item initialization> . 


<item initialization> s= 
<variable denotation> Cinitialization> 
! <label part> <initialization> 


5-0. Statement 


<statement> s= 
<assignment statement> 
| connection statement> 
! if statement> 
! case statement> 
{ <loop statement> 
| <toop exit statement> 
! <subprogram call> 
! return statement> 
! -<with statementd 
{ allocate statement> 
1 <free statement> 
! <symbolic output statement> 
! NULL 


<statement list> «= 
<statement list> (statement) ; 
| <statement> ; 


5-1. Assignment statement 


assignment statement) «= 
<variable denotation> := <expression> 


5-2. Connection statement 


<connection statement> «= 


<program denotation> := ACTION <program dstotarions 


5-3. If statement 


<if statement> «= 
<true part> <else part> END 
| <true part> END 


<true part> x= 
<true part> elsif part> 
1 if part> 


Cif part> «= 
IF <expression> THEN <statement list> 


<elsif part> x= 
ELSIF <expression> THEN <statement list> 


else part> x= 
ELSE <statement list> 


5-4. Case statement 


<case statement> «= 
<case statement head» alternative list) END 


<alternative list) s= 
alternative list) <alternative> 
! alternative> 


case statement head > «= 
CASE <simple expression> OF 


! CASE simple expression) IN <type name> OF — 


<alternative> s= 
<label part> : <statement list 


5-5. Loop statement 


loop statement> == 
<basic loop> 

| iteration condition> <basic loop): 

! <basic loop> <iteration condition> 


<basic loop> #= 
LOOP <loop labei part> : <statement list) REPEAT 
! LOOP <statement list) REPEAT 


<loop label part> «= 
< <identifier> > 


Citeration condition> = 
WHILE <expression> 
! UNTIL <expression> 
1 FOR Cidentifier> := <iteration range> 


<iteration range> = 
EACH <type name> 
! expression) TO <expression> 
! expression) DOWNTO <expression> 


5-6. Loop exit statement 


<loop exit statement> «= 
EXIT < <loop name> >IF Cevprossions: 
! EXIT IF <expression> 
! EXIT < <loop name> > 
! EXIT 


5-7. Subprogram call 


<subprogram call> == 
<program denotation> ( <sequence of parameter assignments > } 
! program denotation> ( <expression> }. 
! <program denotation> : 


<sequence of parameter assignments > == 
<sequence of parameter assignments» , <parameter assignment» 
! <parameter assignment)» 


<parameter assignment> «= 
<value parameter assignment 
1 result parameter assignment> 
1 <value result parameter assignment) 


<value parameter assignment> «= 
<formal parameter> := <expression> 


<result parameter assignment s= 
<formal parameter> =: <variable denotation> 


<value result parameter assignment) «= 
<formal parameter> := : <variable aacoutens 


<formal parameter > e= 
<variable> 


5-8. Return statement 


<return statement> s= 
RETURN <expression> 
| RETURN ~ 
_ | RETURN FROM c<program name> 


5-9. With statement 


<with statement) «= 
WITH <item initialization> DO <statement list> END 


<item initialization >. s= 
<identifier> <initialization> 
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5-10. Allocate and free statements 


(allocate statement> == 
ALLOCATE <variable denotation> <initialization> 
! ALLOCATE <variable denotation> 


Cfree statement> #= 
FREE <variable denotation> 


5-11. Symbolic output statement 


<symbolic output statement> «= 
<symbolic output statement> , (symbolic output element» 
1 QUT <symbolic output element> 


<symbolic output element> #= 
«expression > 
!. TO <simple expression> 
! LINE <simple expression» 
| LINE 
1 PAGE 


6-1. Program body 


“program body> x= 
<program head> <declarative part> <block> 
' program head» <block> 


(program head> s= 
PROGRAM <program denotation) ; 


<declarative part> #= 
declaration list) <list of program bodies> 
1 <declaration list> 
! <list of program bodies» 


<declaration list> #= 
<sequence of declarations» ; 


<sequence of declarations> == 
< sequence of declarations ; <declaration> 
| <declaration> 


<list of program bodies> == 
list of program bodies> <program body > ; 
| <program body» ; 


<block> #= 
' BEGIN statement list> END 


6-2. Compilation 


Ccompilation> #= 
<compilation> <compilation unit> ; 
! context) <compilation unit> ; 
! <Complation unit ; 


Ceontekt a= 
USE DATA <sequence of identifiers) ; 


Cecnpiston ‘unit> s= 
<data segment» 

| program segment> 
| <data partition 

| <program partition> 


6-3. Segments 


<segment declaration> «= 
<sequence of identifiers> : SEGMENT <subprogram type> 


<data segment> == 
DATA SEGMENT Cidentifier> ; (declaration lst) END 
| DATA SEGMENT Cidentifier> ; (declaration list> 
<data implementation part> 


<program segment) «= 
PROGRAM SEGMENT <identifier> ; (declarative part> <block> 
‘| PROGRAM SEGMENT <identifier> ; <block> 
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6-4. Partitions 


<partition declaration> == 
<sequence of identifiers> : PARTITION 
| sequence of identifiers> : TYPE PARTITION 
1 <sequence of identifiers) : EXTERNAL PARTITION 


<data partition> #= 
DATA PARTITION <identifier> ; (declaration list) END 
| DATA PARTITION <identifier> ; (declaration list> 
<data implementation part> 


program partition> = 
PROGRAM PARTITION <identifier> ; “declarative part> END 
! PROGRAM PARTITION <identifier> ; <program implementation part» 
! PROGRAM PARTITION <identifier> ; <declarative part> 
<program implementation part> 


7-1. Impiementation parts 


<data implementation part> == 
IMPLEMENTATION declaration list> END 


program implementation part> == 
IMPLEMENTATION declarative part> END 


<implementation specification» == 
<symbolic type implementation> 
! length specification> 
| array or row implementation > 
! <plex type implementation> 
| <domain implementation> 
| <program implementation> 
! implementation schema> 
! <interface model> 


7-2. Special features 


<type» freed 
<length unit> 


<length unit> x= 
BIT 

! BYTE 

{ HALF 

1 WORD 

! DOUBLE 


<variable denotation> == 
<qualified denotation> 


<qualified denotation> «= 
(<simple expression> AS <type name> ) 


<nature> = 
VULNERABLE 


<indirect name> == 
<schema attribute> 
! <domain attribute> 


7-3. Symbolic type implementation 


<symbolic type implementation > #= 
FOR <type name> USE <aggregate primary» 


7-4. Length specification 


<length specification> «= 
FOR <type name> USE <length unit> <dimension> 
| FOR <type name> USE BASED <length unit> <dimension> 


7-5. Array or row implementation 


<array or row implementation > == 
FOR <type name> USE PACKING 


Ss yntax Summary 


7-6. Plex type implementation 


<plex type implementation> «= 
FOR <type name> USE <plex implementation> 


<plex implementation> = : 
PLEX <attribute implementation list> END 
1 PARALLEL <attribute implementation list> END 


<attribute. implementation list> == 
<attribute implementation list> <attribute specification) ; 
|. attribute specification) ; 


<attribute specification) = 
<attribute : <attribute support). <offset> ~ 
| <attribute : attribute support> 
! <alignment specification> 
! <parailel support» 


<attribute support> «= 
<length unit> ( <origin> : <dimension > ) 
1 <length unit> <dimension> 


<offset> s= 
OF*‘WORD <simple expression> 


<alignment specification> s= 
USE <length unit> 


<parailel support) == 
<identifier> :<length unit> <plex implementation> 


7-7. Implementation schema and domain implementation 


<implementation schema) «= 
SCHEMA <identifier> ; (declaration list> END 


<domain implementation> == 
FOR <domain name> USE <schema name> 


<schema attribute > = 
<schema name> . <attribute» 
! <schema name> . ALLOCATE 
| <schema name> . FREE 


<domain attribute> «= 
<domain name> . <attribute > 


7-8. Interface model and program implementation 


<interface model> s= 
INTERFACE <identifier> ; <register convention list> END 
1 INTERFACE <identifier> ; <register convention list> <block> 
! INTERFACE <identifier> ; <block> 


<register convention list> == 
<register convention list> <register convention) ; 
! register convention) ; 


<register convention> == 
<identifier>.: <mode> <register> 
| RETURN : <register> 
! USE <sequence of registers> 


<sequence of registers == 
<sequence of registers» , register» 
! <register> 


<statement> == 
<inline statement> 


<program implementation > #= 
FOR <program name> USE <interface name> 


7-9. Dynamic coherence 


<membership relation> = 
<primary> COHERENT AS <type name> 


A-1. Prefix specification 


<declaration> == 
<prefix specification> 


<prefix specification> == 
USE PREFIX <type name> 


A-2. Regions 


type > = 
<region type> 


<region type> s= 
REGION list of attribute definitions» END 


<with statement> «= 
RESERVE <item initialization) DO <statement list> END 


A-3. Processes 


<subprogram nature> «= 
PROCESS ACTION 
1 PROCESS PROCEDURE 


<reference type> s= 
REF PROCESS . 


<qualified denotation> «= 
(<simple expression> AS <program name> ) 
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